Re: clone_schema function - Mailing list pgsql-general

From Melvin Davidson
Subject Re: clone_schema function
Date
Msg-id CANu8Fix_YNH9_+9rhBPchnmKSjCBiL+aGxiF=9G2gP9xc9obZw@mail.gmail.com
Whole thread Raw
In response to Re: clone_schema function  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-general
With thanks to a suggestion by David G. Johnston, I've attached another revised version
of the function that hopefully eliminates the problem reported by Daniel Verite.
This version also handles CamelCase schemas and tables better.

If anyone else finds a problem, kindly attach a dump of the schema to duplicate the problem.


On Sat, Sep 12, 2015 at 10:38 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
        Melvin Davidson wrote:

> "seriously flawed" is a bit of a stretch. Most sane developers would not
> have schema names of one letter.
> They usually name a schema something practical, which totally avoids your
> nit picky exception.

That's confusing the example with the problem it shows.

Another example could be:
if the source schema is "public" and the function body contains
   GRANT SELECT on sometable to public;
then this statement would be wrongly altered by replace().

My objection is not about some corner case: it's the general
idea of patching the entire body of a function without a fully-fledged
parser that is dead on arrival.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Attachment

pgsql-general by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: clone_schema function
Next
From: Jeff Janes
Date:
Subject: Re: Forced external sort?