Robert Haas wrote:
> On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera <alvhe...@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...
I don't think it is necessary to force parsing strings for something
that can be more conveniently obtained from the get go, just because
we're too lazy to change the existing definition of the function. I'm
not saying it is impossible or extremely hard to parse the strings, but
since we can emit the right format with no extra effort, there doesn't
seem to be any point on doing it that way. It's not like this patch
adds excessive extra complexity to this code, either.
I'd say that the most complex part of this patch is the addition of the
two flag ("normal" and "original") columns, which we would need
regardless of the rest of the patch; these are used to tell whether
there are routes to the given object that have the eponymous flags set
in the dependency graph.
> > 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.
We have a main parser because we have no other option --- it's the way
stuff gets into the system in the first place. But in this case, it's
not about accepting communication from the outside world, but emitting
state that is already in the database, in a different format.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
