public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: generating function default settings from pg_proc.dat
Date: Mon, 16 Feb 2026 16:46:36 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<lfzlruyq64npjz4z3aiiox2nzg6astxuy5sgmyxm2kwvty4fgq@zcfrpu5jhw5o>
	<[email protected]>
	<dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>
	<[email protected]>
	<[email protected]>

Andrew Dunstan <[email protected]> writes:
> On 2026-02-16 Mo 3:02 PM, Tom Lane wrote:
>> Who's going to work on this?  I'm happy to take a swing at it,
>> but don't want to duplicate someone else's effort.

> Go for it. I'm happy to review.

After a little bit of thought, I propose the following sketch
for what to do in the bootstrap backend:

In InsertOneValue(), add a special case for typoid == PG_NODE_TREEOID.
pg_node_tree_in() would just fail anyway so this isn't removing
any useful functionality.  The special-case code would check which
column we are entering a value for and dispatch to appropriate code:

       if (typoid == PG_NODE_TREEOID)
       {
           if (RelationGetRelid(boot_reldesc) == ProcedureRelationId &&
	       i == Anum_pg_proc_proargdefaults - 1)
	       values[i] = ConvertOneProargdefaultsValue(value);
	   else
	       ... maybe other cases later
	   else
	       elog(ERROR, "can't handle pg_node_tree input");
	   return;
       }

This framework would permit special-casing other catalog columns
in future, if we feel a need for that.

Andres was concerned about not having access to the other columns of
pg_proc, but I think that's mistaken: bootstrap.c's values[] array
should hold the already-parsed values of all earlier columns for the
current entry.  So ISTM that we should have enough data to interpret
an input that just looks like an array of input-value strings and
construct a List of Const nodes from that, then flatten it to a
nodetree string.

So with that we'd have enough infrastructure to allow writing
something like

	proargdefaults => '{1,2,true}'

This seems orthogonal to Andres' suggestion about refactoring
the pg_proc.dat representation of arguments to not be parallel
arrays but a list of hashes.  I think that's likely a good
idea, but I don't want to implement it because I'm not a great
Perl programmer.  Do you want to pick up that part?

			regards, tom lane

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: generating function default settings from pg_proc.dat
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox