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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
