Re: replicating DROP commands across servers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replicating DROP commands across servers
Date: 2014-10-05 01:12:24
Message-ID: CA+TgmoaUH4+vUZATS6egn_pr7DxBpvBf0DhJO_Lr5xSwCgJWrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-10-05 06:57:44 Re: Aussie timezone database changes incoming
Previous Message Andrew Gierth 2014-10-05 01:07:55 Re: NEXT VALUE FOR <sequence>