Re: Controlling changes in plpgsql variable resolution

On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> If possible, I think we should try to engineer things so that using
>> pg_dump 8.5 on an 8.4 database and restoring the result into an 8.5
>> database produces a function with identical semantics.
>
> Hmm ... actually, we could have pg_dump stick either a #option line
> or a GUC SET parameter onto every plpgsql function it pulls from an
> old database.  So if you're willing to assume that people do their
> upgrades that way, it could be made reasonably safe, even if the
> default behavior changes.

I'm not completely willing to assume that. I know we recommend it,
but I'm sure that people don't always do it. And this is pretty
subtle: someone might screw it up and get a non-working function
without realizing it. The advantage of making the default behavior
"throw an error" is that it should be pretty obvious if you've broken
something.

And this isn't just about pg_dump, either. I have a script that gets
run regularly on one of my production databases that goes an updates
the definitions of a whole bunch of functions to the latest version
from the source code repository. Even if pg_dump DTRT, the next run
of a script of that type might subtly break a bunch of stuff.

The current behavior is a trap for the unwary, so I have no problem
with changing it. But I think we should try really hard to avoid
creating a more subtle trap in the process.

...Robert