Re: Deparsing DDL command strings

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Why don't you just pass the original query string, instead of writing
>> a mass of maintenance-requiring new code to reproduce it?

> Do we have that original query string in all cases, including EXECUTE
> like spi calls from any PL?

As I said, I believe we are pretty close to that if not there already.
There are a number of utility statements that *require* the source
string to be provided, because they do parse analysis and since 8.4 or
so the original string has been required for that. So we certainly have
the string available at ProcessUtility. I've not looked at the event
trigger patch at all, so I don't know what amount of refactoring is
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.

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

> Those tools could also use the Node *parsetree and be written only in C,
> but then what about giving them a head start by having a parsetree
> walker in our code base?

Well, as far as a raw parsetree *walker* goes, there already is one in
nodeFuncs.c. It does not follow that we need something that tries to
reconstruct SQL from that. It's not clear to me that there is any
production-grade use-case for which reconstructed SQL is more useful
than examining the parse tree. Now, if you're talking about half-baked
code that gets only some cases right, then yeah grepping reconstructed
SQL might serve. But I'm not excited about doing a lot of work to
support partial solutions.

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

> My freshly grown limited understanding is that we currently only know
> how to produce a "cooked" parse tree from the raw one if all referenced
> objects do exist in the catalogs,

Well, yeah. Anything else is magic not code.

regards, tom lane