Re: The missing pg_get_*def functions

On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Noah Misch <noah(at)leadboat(dot)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.