Re: clone_schema function

I still do not see any problem. The whole purpose of the function is to
copy ALL sequences , tables and functions to "new" schema, so new.old WILL
exist.

I don't see how you can possibly write a function that references a schema
that does not yet exist!

Again, please provide a _working_ example of what you think the problem is.

On Tue, Sep 15, 2015 at 3:22 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 9/14/15 8:02 PM, Melvin Davidson wrote:
>
>> Actually, on further thought, you example shows that it works correctly
>> because we do want all references to the old schema to be changed to the
>> new schema, since all copies of functions will now reside in the new
>> schema. Otherwise, there is no point of duplicating those functions.
>>
>
> Read my example again:
>
> SELECT old.field FROM old.old;
>
> That will end up as
>
> SELECT new.field FROM new.old
>
> Which will give you this error:
>
> ERROR: missing FROM-clause entry for table "new"
> LINE 1: SELECT new.field FROM new.old;
>
> Even if you could fix that, there's yet more problems you'll run into,
> like if someone has a plpgsql block with the same name as the old schema.
>
> I'm not trying to denigrate the work you and others have put into this
> script, but everyone should be aware that it's impossible to create a
> robust solution without a parser. Unfortunately, you could end up with a
> function that still compiles but does something rather different after the
> move. That makes the script potentially dangerous (granted, the odds of
> this are pretty low).
>
> One thing I think would be very interesting is a parser that preserves
> whitespace and comments. That would allow us to store a parsed version of
> (at least plpgsql and sql) functions. The same technique would also be
> handy for views. This would allow a lot (all?) other renames to propagate
> to functions instead of breaking them (as currently happens).
>
> Another option is supporting some kind of official way to specially
> designate database objects in any procedure language (ie, the @schema@
> syntax that extensions use). That would make it possible to rename properly
> written functions without adverse side effects.
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>

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