2011/12/19 Robert Haas <robertmh...@gmail.com>: > On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith <g...@2ndquadrant.com> wrote: >> That seems pretty sensible; I wouldn't want to make it a hard requirement >> though. There are three major ways this could go for 9.2: >> >> 1) Nothing is changed in core, the best that can be done is whatever you can >> cram into an extension. >> >> 2) 9.2 is released with Command Triggers using nodeToString() output as the >> detailed description. That part is labeled "experimental and the API is >> expected to change completely in the next release" >> >> 3) 9.2 gets enough JSON support to also have an early nodeToJSON API >> instead. Now it's labeled "early release and some API changes may be needed >> in future releases". >> >> From the perspective of enabling a developer community to spring up around >> working in this area, I don't see a huge difference between (2) and (3). > > 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. > People in PL/python and PL/perl may be a bit better off, but I see no > reason to ship something for 9.2 and then break it for 9.3 when we > could perfectly well make that compatibility break before the release. > (And, in case it's not clear, yes, I am volunteering to do the work, > if it comes down to that.)
absolutelly Parsing a some document is not a good way for plpgsql. We can enhance a diagnostics statement for triggers values. there should be lot of variables, and it is cheap because we can take content when it is requested STATEMENT_NAME, OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_OID, ATTRIBUT_NAME, ATTRIBUT_OID, ATTRIBUT_TYPE, STATEMENT_PARAMETERS_ARRAY plpgsql is not good for recursive data - can be nice if all necessary data can be flat. Regards Pavel > > 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. > > On the flip side, I don't really see any other way to make this > feature work at all. I think that AFTER CREATE triggers and BEFORE > DROP triggers could potentially be implemented by just passing OIDs > in, and that might be useful enough for many people. But what about > ALTER? I don't see that you're going to be able to write any sort of > meaningful triggers around ALTER without passing at least some of the > parse tree information to the trigger function. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
