Re: Enhancement request for pg_dump

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Sergei Agalakov <Sergei(dot)Agalakov(at)getmyle(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Enhancement request for pg_dump
Date: 2016-04-18 14:22:25
Message-ID: 5714EDA1.8010800@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Albe Laurenz 2016-04-18 14:35:50 Re: How do BEGIN/COMMIT/ABORT operate in a nested SPI query?
Previous Message Adrian Klaver 2016-04-18 14:12:31 Re: pg_basebackup: return value 1: reason?