Re: Command Triggers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On Monday, December 19, 2011 05:12:13 PM Robert Haas wrote:
>> I do. Anyone coding in PL/pgsql is going to find the nodeToString()
>> output unusable, and we can easily provide a built-in JSON datatype
>> with enough richness to make that problem go away in time for 9.2.

I hear the sound of goalposts moving.

> I personally think youre underestimating the complexity of providing a
> sensible json compatibility shim ontop the nodestring representation. But I
> would like to be proven wrong ;)

If we were going to do this at all, the way to do it is to flush the
existing nodestring representation and redefine it as being JSON. No?
If this is as easy as people are claiming, it should not be hard to
revise the lower-level bits of outfuncs/readfuncs to make the text
representation compatible. And there's no reason we can't change
what is stored in pg_rewrite.

>> But before we get bogged down in the data representation, I think we
>> need to make a more fundamental decision: to what extent are we OK
>> with exporting the parse tree at all, in any form? Tom is arguing
>> that we shouldn't, and I see his point: the recent DROP command rework
>> would have broken everybody's command triggers if we had adopted this
>> proposal, and that would be a real shame, because I don't particularly
>> like the idea that we can't continue to improve the code and refactor
>> things because someone out there might be depending on an older and
>> less well-considered behavior.

The problem that changing the nodestring representation could help with
is making user-written triggers roughly as robust as C code is, to wit
that you don't have to change it as long as the specific fields it
touches aren't redefined. The question is whether that's good enough.
The DROP command changes provide a pretty strong clue that it isn't.
Admittedly, that's not the sort of change we make too often. But I
will be seriously annoyed if we start getting the sort of pushback
on parsetree changes that we've been hearing from certain quarters about
configuration file changes. Those structures are *internal* and we have
got to have the flexibility to whack them around.

regards, tom lane