On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
