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