On Tue, Apr 30, 2013 at 11:22 AM, Andrew Dunstan <and...@dunslane.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.
Nothing in the versioning policy* appears to be in conflict with fixing bugs in
pg_catalog sql-language functions. Maybe it's an unwritten rule minor versions
mustn't affect the pg_catalog. I thought the rule was to require no
data relational
modifications of pg_catalog between minor versions, but simply modifying or
adding functions, without breaking their interfaces, is not a modification of
the pg_catalog as I see it, as it couldn't affect any old code, since the tables
and columns would be untouched. Old code couldn't be affected of new functions,
or the inner-details of existing pg_catalog functions, as long as they
don't change
the interface, i.e., the IN/OUT parameters.
I would actually want to go a bit further and propose to move the sql queries
within the "else if (fout->remoteVersion >= ...) { ... }" statements also for
_old_ versions, and put them in sql-language functions, which, if you would
use a future version of pg_dump to dump an old version, would install
sql-language functions for the old version in pg_catalog, so they could
be called by the new pg_dump.
That way we could get rid of these kind of sql queries for _all_ versions,
and not just for future versions.
These functions would need to adhere to exactly the same interface,
where the OUT params must fit perfectly with the args passed to ArchiveEntry().
The existing pg_get_*def() are not comprehensive enough, as they still require
a lot of sql code to extract various other necessary fields.
*) http://www.postgresql.org/support/versioning/
> 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
