Re: The missing pg_get_*def functions

On 04/30/2013 07:34 AM, Joel Jacobson wrote:
> On Tue, Apr 30, 2013 at 11:22 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Minor releases are supposed not to require any such operations. You should
>> normally be able to drop the binaries in place and restart. For C language
>> functions that is indeed all you have to do, but that's not the case for SQL
>> language functions, where the definition is contained in the catalogs, not
>> the binary.
> Minor releases don't even require pg_dump/pg_restore, so I really
> don't see the issue.

You have already been told what the issue is. There is no provision for
updating the catalogs. Our users expect to be able to drop a minor
upgrade binary in place and have nothing more to do. It's what they are
used to and I at least have no interest in changing that. If you change
the definition of provided SQL language functions you would need to
apply those changes to each database in each cluster. Otherwise, a user
will think they are on version X which has a fix for function Y and in
fact they won't have the fix. That's a recipe for utter confusion.

All the existing pg_catalog SQL functions are one liners, apart from
ts_debug().

>> If all you want is SQL language functions, there is nothing to stop you from
>> writing them and publishing them today as an extension.
> Yes, maybe I will, as a proof-of-concept and test of how complex or simple it
> would be, and how many lines of code pg_dump.c could be reduced with.
>

pg_dump does bulk operations in many cases, and one way we could make it
faster would be to increase that, not reduce it (see comments where we
get table attributes in pg_dump.c, for example). Providing singleton
operations like this will not help it at all.

If your aim is to be able to replace all the code pg_dump runs by these
singleton operations then I think it's almost certainly doomed to failure.

Having undertaken some of the exercise, I can also assure you that
writing pg_get_table_def() in a single pure SQL statement will be ....
challenging.

There is a case for having functions like these, but probably not for
use by pg_dump, and I suspect they would best be done in C.

cheers

andrew