Jim, Have you actually tried this, or is it just a theory? AFAIK, the function will work because only the schema name is changed.. So please provide a full working example of a function that fails and I will attempt a solution.
On Mon, Sep 14, 2015 at 6:36 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 9/12/15 9:38 AM, Daniel Verite 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(). >> > > Well, the new version actually fixes that. But you could still trip this > up, certainly in the functions. IE: > > CREATE FUNCTION ... > SELECT old.field FROM old.old; > > That will end up as > > SELECT new.field FROM new.old > > which won't work. > > 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. >> > > ISTM that's also the biggest blocker for allowing extensions that refer to > other schemas to be relocatable. It would be interesting if we had some way > to handle this inside function bodies, perhaps via something equivalent to > @extschema@. > -- > 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.
