Обсуждение: Improve pg_trigger.tgargs representation

I always found the encoding of the pg_trigger.tgargs field quite weird 
and archaic.  (It encodes the trigger argument list into a bytea 
column.)  So I tried replacing this with a list of nodes in a 
pg_node_tree.  This worked out quite nicely.  It makes the internal code 
much simpler, and it would maybe also allow clients to decode the column 
more easily.

(Trigger arguments are all strings, so another representation might be 
an array of text, but I think a node representation makes more sense. 
For example, you could imagine encoding numeric constants more directly, 
but this is not done here.)

Note that clients shipped with PostgreSQL (such as psql and pg_dump) use
pg_get_triggerdef() and don't access the field directly, so they need no 
changes.  (See also [0].)  I don't know about other clients, such as 
third-party GUIs.

Now, I don't really know if this is worth actually moving forward with, 
unless perhaps someone has additional arguments in favor.  But I figured 
it was worth sharing as an idea.


[0]: 
https://www.postgresql.org/message-id/flat/56c8f5bf-de47-48c1-a592-588fb526e9e6%40eisentraut.org

Peter Eisentraut <peter@eisentraut.org> writes:
> I always found the encoding of the pg_trigger.tgargs field quite weird 
> and archaic.  (It encodes the trigger argument list into a bytea 
> column.)

It is that ...

> So I tried replacing this with a list of nodes in a 
> pg_node_tree.  This worked out quite nicely.  It makes the internal code 
> much simpler, and it would maybe also allow clients to decode the column 
> more easily.

> (Trigger arguments are all strings, so another representation might be 
> an array of text, but I think a node representation makes more sense. 
> For example, you could imagine encoding numeric constants more directly, 
> but this is not done here.)

I come down on the other side of that: if we change this we should
change to array-of-text.  I think expecting clients to be able to
decode pg_node_tree is an absolutely horrid idea: it's overly complex
and we change the representation constantly.

Also, while I see that indeed none of our client-side code looks
directly at pg_trigger.tgargs anymore, there is a lot of backend and
contrib code (and therefore likely also 3rd-party extension code) that
depends on the representation used in struct Trigger ... which is
array of C strings.  I do not think we dare change that.

On the whole I'm not sure this is worth messing with.  We run at least
some risk of breaking somebody's code, and it doesn't seem like we
gain much unless we're willing to change struct Trigger, which'd
break a *lot* of code.

            regards, tom lane