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.na...@bluetreble.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.
