On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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...).
It would be better to find a way to update sql-language functions in minor upgrades, instead of shutting that door entirely for all future implementation ideas involving sql-language functions in the pg_catalog. > 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. There are two very good reasons in particular of doing exactly that: a) Make it possible to develop tools which need to be able or create (and/or drop) schema objects, such as a schema migration tool, capable of migrating between different revisions of the schema. I started working on such a project two years ago, but realised most of the actual code I wrote was code to define how to create/drop objects, and in what order based on pg_depend, and I thought such code would be better to put in the core, and put the project on hold awaiting a complete coverage of the pg_get_*def functions, but they never happened, so here we are two years later. This is the project I'm talking about: https://github.com/gluefinance/pov b) Reduce the amount of hard-coded sql queries in pg_dump.c. Won't help for previous versions, but perhaps the sql queries to support older versions can be hidden in some separately included file at least so you don't have to see it, which would make sense since the sql for the old versions won't change and won't need the same amount of active development as the code for the latest version. Makes no sense of keeping the sql for all versions at the same place. > 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. I don't agree with you as I don't think it's a very hard problem to deal with updates of sql-language functions in the pg_catalog schema. If we fix that first, this and a whole range of problems, where the solution involves taking in-data from pg_catalog, and producing out-data based on that, becomes super easy to achieve by writing simple sql-language functions with direct and simple access to the pg_catalog, instead of writing C functions with inline hard-coded sql. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
