Re: replicating DROP commands across servers

On 2014-10-04 21:12:24 -0400, Robert Haas wrote:
> 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 ".

I'm not following here. Maybe just because I'm misunderstanding your
position.

The patch imo consists out of the following parts:
1) Addition of dependency information to the dropped object list
2) Actual get_object_address() handling for default values - the current
behaviour looks pretty borked to me.
3) The reverse of getObjectTypeDescription()
4) getObjectIdentityParts() - a slightly more detailed version of
getObjectIdentity() that requires less string parsing
5) drop even trigger support for a few types.

Are you saying you want to add a function to do 4) via parsing inside
postgres or are you suggesting to do that in every user of this
facility?

If the former, why would it be preferrable to do string parsing if we
have access to the source data? That part of the patch looks trivial to
me?

If the latter, I don't see the advantage either - this is complicated
enough, why should different users repeat the work?

Am I misunderstanding you here?

Having reread the patch just now I basically see two things to
criticize:
a) why isn't this accessible at SQL level? That seems easy to address.
b) Arguably some of this could well be done in separate commits.

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

Which happens to be the part of postgres that's copied most often. So
it's certainly not something appearing to be trivial.

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

That parser also happens to be far from trivial (if we're talking about
parseNameAndArgTypes() - which just solves one of the cases.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services