Tom Lane <t...@sss.pgh.pa.us> writes: > going to be required below that ... but the point I'm trying to make is > that it would be a one-and-done task. Adding a requirement to be able > to decompile raw parse trees will be a permanent drag on every type of > SQL feature addition.
I'll show some examples of very involved command (CREATE and ALTER TABLE are the most complex we have I think) and some very simple commands (DROP TABLE is one of the simplest), so that we can make up our minds on that angle. >> Then we want to qualify object names. Some type names have already been >> taken care of apparently by the parser here, relation names not yet and >> we need to cope with non existing relation names. > > Which is exactly what you *won't* be able to do anything about when > looking at a raw parse tree. It's just a different presentation of the > query string. So, I'm currently adding the deparsing to the existing only event we have, which is ddl_command_start. That's maybe not the best place where to do it, I even now wonder if we can do it there at all. Doing the same thing at ddl_command_end would allow us have all the information we need and leave nothing to magic guesses: full schema qualification of all objects involved, main object(s) OIDs available, all the jazz. > Well, yeah. Anything else is magic not code. Well, prepending an object name with the first entry of the current search_path as its schema is not that far a stretch when the object is being created, as far as I see it. It's more reasonable to document that the rewritten no-ambiguities command string is only available for ddl_command_end events, though. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
