Re: clone_schema function

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(dot)Nasby(at)bluetreble(dot)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(at)(dot)
> --
> 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.