Re: Command Triggers

On Mon, Dec 19, 2011 at 12:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

I thought about that. A quick inspection suggests that this would
slightly increase the size of the stored rules, because the node type
would need to become a key, which would add at least a few more
characters, and also because we'd need more quoting. That is:

{THING :wump 1}

becomes, at a minimum:

{"_": "THING", "wump": 1}

And that's using a somewhat-lame single character label for the node
tag. Now, I suspect that in practice the cost of the stored rules
becoming slightly larger is negligible, so maybe it's worth it.

>>> 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.

Agreed.

> 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.

Yes.

Maybe we should try to split the baby here and defer the question of
whether to expose any of the parse tree internals, and if so how much,
to a future release. It seems to me that we could design a fairly
useful set of functionality around AFTER-CREATE, BEFORE-DROP, and
maybe even AFTER-ALTER triggers without exposing any parse tree
details. For CREATE and ALTER, that would make it the client's
responsibility to inspect the system catalogs and figure out what had
happened and what to do about it, which is admittedly not ideal, but
it would be more than we have now, and it would then give us the
option to consider requests to expose more information in future
releases on a case-by-case basis, rather than making a blanket
decision about whether to expose the parse tree or not. I have a
sneaking suspicion that, while we probably can't get by without
exposing any parse tree information ever, the amount we truly need to
expose might end up being only a small percentage of the total...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company