Re: Deparsing DDL command strings

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deparsing DDL command strings
Date: 2012-10-08 13:30:05
Message-ID: m2lifhgkgy.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-10-08 13:39:10 Re: [COMMITTERS] pgsql: Disable _FORTIFY_SOURCE with ICC
Previous Message Andrew Dunstan 2012-10-08 13:25:41 odd alter_generic regression failures