Re: Deparsing DDL command strings

On 10/5/12 11:15 AM, Tom Lane wrote:
>> Also, we need to normalize that command string. Tools needing to look at
>> >it won't want to depend on random white spacing and other oddities.
> Instead, they'll get to depend on the oddities of parse transformations
> (ie, what's done in the raw grammar vs. what's done in parse_analyze),
> which is something we whack around regularly.  Besides which, you've
> merely asserted this requirement without providing any evidence that
> it's important at all, let alone important enough to justify the kind of
> maintenance burden that you want to saddle us with.

I definitely want to be able to parse DDL commands to be able to either enforce things or to drive other parts of the
systembased on what's changing. Without the ability to capture (and parse) DDL commands I'm stuck creating wrapper
functionsaround anything I want to capture and then trying to ensure that everyone uses the wrappers and not the raw
DDLcommands.
 

Event triggers that just spit out raw SQL give me the first part of this, but not the second part: I'm still stuck
tryingto parse raw SQL on my own. Having normalized SQL to parse should make that a bit easier, but ideally I'd like to
beable to pull specific elements out of a command. I'd want to be able to do things like:
 

IF command is ALTER TABLE THEN  FOR EACH subcommand    IF subcommand IS DROP COLUMN THEN      do something that needs
toknow what column is being dropped    ELSE IF subcommand IS ADD COLUMN THEN      do something that needs to know the
definitionof the column being added
 

I don't think every bit of that has to be dealt with by the event trigger code itself. For example, if you're adding a
columnto a table and the entries have already been made in the catalog, you could query to get the details of the
columndefinition if you were given an OID into pg_attributes.
 

Having said all that, an event system that spits back the raw SQL would certainly be better than nothing. But realize
thatpeople would still need to do parsing on it (ie: replication solutions will need to know what table just got
ALTER'd).
-- 
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net