Re: Enhancement request for pg_dump - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Enhancement request for pg_dump
Date
Msg-id 5714EDA1.8010800@aklaver.com
Whole thread Raw
In response to Re: Enhancement request for pg_dump  (Sergei Agalakov <Sergei.Agalakov@getmyle.com>)
List pgsql-general
On 04/17/2016 05:50 PM, Sergei Agalakov wrote:
> Nobody asks for pg_dump to be a schema comparison tool. As you tell
> yourself
> it is a most reliable schema capturing tool. All I am asking is that if
> pg_dump is executed
> on two databases with the identical schemas and security it should be
> able to produce
> the identical SQL dumps of these schemas and security. As you have
> mentioned in other e-mail
> pg_dump actually rewrites some statements for consistency. It just
> doesn't do it consistently everywhere.

And there in lies the rub. Making that happen, I suspect, is going to be
a lot of work. The goal of the tool is not to produce output that is
diff friendly but that produces working schema when transferred to
another database. I understand what you want and why I just think it is
not as easy as you want to believe. See my other post for ways to try to
make this happen.

>
> I can't say anything about priorities of development for pg_dump. The
> proposed change seems to be
> a low hanging fruit, it isn't difficult to add ORDER BY in the
> appropriate places. The other question is if
> this is a useful enhancement. The existence of the third party tools
> doesn't seem to be very relevant here.
> Should be stopped the development of pgAdmin or psql because exist the
> third party tools with the similar functionality?
> :-)

FYI, pgAdmin is a third party tool, currently being completely rewritten:

http://pgsnake.blogspot.com/2016/04/pgadmin-4-elephant-nears-finish-line.html

>
> Sergei
>



--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: pg_basebackup: return value 1: reason?
Next
From: Albe Laurenz
Date:
Subject: Re: How do BEGIN/COMMIT/ABORT operate in a nested SPI query?