Noah Misch <n...@leadboat.com> writes:
> Note also that minor releases can readily fix bugs in C-language functions,
> but we have no infrastructure to update sql-language functions after initdb.
> That flexibility is unfortunate to lose, particularly for something that
> pg_dump depends on.
That alone would probably be sufficient reason why we would never allow
pg_dump to depend on any such thing (not that I see a compelling
argument for it to do so anyway...).
The long and the short of it here is that there isn't any very good
reason to migrate any of the existing pg_dump-side functionality into
server-side functions, and especially not server-side functions that
aren't in C. One of the things that we frequently recommend when doing
upgrades is that you do the dump with the newer version's pg_dump, so
as to get the benefits of any bug fixes that are in it. The more
dump functionality is on the server side, the less opportunity we have
to repair things that way.
It may be that the functions Joel proposes are worth having for other
tools to use, but I'm not in favor of making pg_dump use them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
