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.Nasby@xxxxxxxxxxxxxx> 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.![]()
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
