Re: Schema version management - Mailing list pgsql-hackers

On Mon, May 21, 2012 at 10:06 AM, Daniel Farina <daniel@heroku.com> wrote:
> Also, now that I look more carefully, there was a lot of conversation
> about this patch; it seems like what you are doing now is reporting
> its successful use, and I did not understand that by reading the
> abstract of your email.  And, beyond that, do we have a summary of the
> open questions that prevented it from being committed?

Good idea. Here is an attempt to a summary:

http://archives.postgresql.org/pgsql-hackers/2010-12/msg02301.php
The initial feedback was on the usage of OIDs as file names.
This was indeed a bad idea and was changed, see
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02314.php
Tom Lane also pointed out it doesn't solve the "randomly different
ordering of rows within a table"-problem.
The rows within a table are not part of the schema. The patch doesn't
attempt to solve that problem.

http://archives.postgresql.org/pgsql-hackers/2010-12/msg02318.php
Gurjeet Singh pointed out the problem with functions sharing the same
name but having different arguments.
As of now, it's not certain they will always be dumped into the same files.
This is a valid point, and needs to be solved in an elegant way.
The arguments needs to be made part of the path somehow.

http://archives.postgresql.org/pgsql-hackers/2010-12/msg02327.php
Another idea Gurjeet had was to hash the object identifier and use
that in the file's name.
Not a bad idea, would look nicer if functions have very many arguments.
Perhaps /[schema]/[object type]/[name]/[hash of arguments].sql

http://archives.postgresql.org/pgsql-hackers/2010-12/msg02329.php
David Wilson suggested placing all overloaded functions within the same file.
"Then, assuming you order them deterministically within that file, we
sidestep the
file naming issue and maintain useful diff capabilities, since a diff of the
function's file will show additions or removals of various overloaded
versions."
This would be a good idea, but falls on pg_dump not outputting the
functions in a deterministic order.

http://archives.postgresql.org/pgsql-hackers/2010-12/msg02496.php
Robert Treat: "I've both enjoyed reading this thread and seeing this wheel
reinvented yet again, and wholeheartedly +1 the idea of building this
directly into pg_dump. (The only thing better would be to make everything
thing sql callable, but that's a problem for another day)."

> My thinking is that confidence would be increased if there was a piece
> of code that handled a lot of the catalog munging et al that is part
> of pg_dump that *is* maintained by postgres so other projects can more
> convincingly add a correct veneer.

I totally agree, the most easy place to handle it is within pg_dump.

> As a meta-comment, all I did was ask some polite questions.  You could
> have politely disqualified pg_extractor and spared some of the
> language without having gotten anything less done.

I very much appreciated your answer, and I did in no way mean to be impolite.

Best regards,

Joel