On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> I'm not really very convinced that it's a good idea to expose this
>> instead of just figuring out a way to parse the object identity.
>
> That's the first thing I tried. But it's not pretty: you have to
> extract schema names by splitting at a period (and what if a schema name
> contains a period?),
Please tell me that the literals are escaped if necessary. If so,
this is pretty easy. quote_literal() is not a hard transformation to
reverse, and splitting on a unquoted period is not hard...
> split out on ON for certain object types,
...nor is splitting on any other fixed text string, such as " ON ".
> figure
> out parens and argument types and names for functions and aggregates,
> etc.
I certainly agree that parsing out parens and argument types and names
for functions and aggregates is the hardest part of this, mostly
because you can't count a comma to mark the end of one argument and
the beginning of the next - you have to account for quoted
identifiers, and you might be inside a numeric typemod or similar.
> It's just not sane to try to parse such text strings.
But this is a pretty ridiculous argument. We have an existing parser
that does it just fine, and a special-purpose parser that does just
that (and not all of the other stuff that the main parser does) would
be a great deal simpler. Maybe there are examples other than the ones
you listed here that demonstrate that this is actually a hard problem,
but the fact that you might need to undo quote_literal() or search for
and split on fixed strings does not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
