On 04/22/2016 11:16 AM, Pierre Chevalier Géologue wrote:
Le 22/04/2016 19:11, Adrian Klaver a écrit :
Last time I had to do this kind of exercise, a few years ago, I was in a
remote place without Internet access, so I could not get any information
or ask any help. I was kind of surprised/frustr
Le 22/04/2016 19:11, Adrian Klaver a écrit :
Last time I had to do this kind of exercise, a few years ago, I was in a
remote place without Internet access, so I could not get any information
or ask any help. I was kind of surprised/frustrated by the (apparent)
lack of order of the pg_dump output
On 04/22/2016 09:44 AM, Pierre Chevalier Géologue wrote:
> Hi,
> Le 18/04/2016 02:26, Sergei Agalakov a écrit :
>
>> If you never encountered a situation when in the dozens of
>> environments the databases has diverged because somebody has
>> done something manually - good for you, you are lucky g
Le 18/04/2016 03:10, Sergei Agalakov a écrit :
I just wanted to check that my request will have the peoples support.
So far it doesn't.
Well, you can count on my support, for sure!
It looks like that or people never need to compare two PG databases
to find the differences in the schemas or s
Hi,
Le 18/04/2016 02:26, Sergei Agalakov a écrit :
If you never encountered a situation when in the dozens of
environments the databases has diverged because somebody has
done something manually - good for you, you are lucky guy then.
I'm definitely not a lucky guy at all! :-)
And this is happ
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 pro
On 04/17/2016 06:10 PM, Sergei Agalakov wrote:
Thank you, I know this place.
I just wanted to check that my request will have the peoples support.
So far it doesn't. It looks like that or people never need to compare
two PG databases to find the differences in the schemas or security,
or happy to
On 18 April 2016 at 13:10, Sergei Agalakov wrote:
> Thank you, I know this place.
> I just wanted to check that my request will have the peoples support.
> So far it doesn't. It looks like that or people never need to compare two PG
> databases to find the differences in the schemas or security,
>
Thank you, I know this place.
I just wanted to check that my request will have the peoples support.
So far it doesn't. It looks like that or people never need to compare
two PG databases to find the differences in the schemas or security,
or happy to use the third party tools to do it, and don't
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
fyi, if you have a feature request or enhancement, then the proper place
for that is here -> https://postgresql.uservoice.com/forums/21853-general
On Sun, Apr 17, 2016 at 8:26 PM, Sergei Agalakov <
sergei.agala...@getmyle.com> wrote:
> I hardly can see that a sorting of the grants by users will
I hardly can see that a sorting of the grants by users will create a
measurable impact on the pg_dump performance in a real database.
One can imaging a database with tens of thousands of objects and tens of
thousands of users and almost no data, but it would be quite unusual.
Anyway, if a sorting
On 04/17/2016 01:58 PM, Adrian Klaver wrote:
On 04/17/2016 01:10 PM, Sergei Agalakov wrote:
I don't see how these questions are related to the proposed pg_dump
improvement.
I suggest to improve pg_dump so it can be used instead of the third
party tools like DBSteward and SQLWorkbench/J etc.
to c
On 04/17/2016 01:10 PM, Sergei Agalakov wrote:
I don't see how these questions are related to the proposed pg_dump
improvement.
I suggest to improve pg_dump so it can be used instead of the third
party tools like DBSteward and SQLWorkbench/J etc.
to compare two different databases or existing dum
On 04/17/2016 01:10 PM, Sergei Agalakov wrote:
I don't see how these questions are related to the proposed pg_dump
improvement.
I suggest to improve pg_dump so it can be used instead of the third
party tools like DBSteward and SQLWorkbench/J etc.
to compare two different databases or existing dum
On Sun, 17 Apr 2016 14:10:50 -0600
Sergei Agalakov wrote:
> I don't see how these questions are related to the proposed pg_dump
> improvement.
> I suggest to improve pg_dump so it can be used instead of the third
> party tools like DBSteward and SQLWorkbench/J etc.
> to compare two different da
I don't see how these questions are related to the proposed pg_dump
improvement.
I suggest to improve pg_dump so it can be used instead of the third
party tools like DBSteward and SQLWorkbench/J etc.
to compare two different databases or existing dumps, and to identify
the differences. The use c
It can be done of course, but as you can see in my examples the
statements in pg_dump generated scripts are grouped together by the objects.
It is easier to analyze the differences when all these differences for
an object are clustered together, and aren't dispersed in the diff file.
It also wil
On Sat, 16 Apr 2016 13:33:21 -0600
Sergei Agalakov wrote:
> Hi,
>
> Currently as in PG 9.4, 9.5 the order of the statements in the script
> produced by pg_dump is uncertain even for the same versions of the
> databases and pg_dump.
> One database may script grants like
>
> REVOKE ALL ON TABLE
On Sat, Apr 16, 2016 at 01:33:21PM -0600, Sergei Agalakov wrote:
> Currently as in PG 9.4, 9.5 the order of the statements in the script
> produced by pg_dump is uncertain even for the same versions of the databases
> and pg_dump.
> One database may script grants like
>
> REVOKE ALL ON TABLE cont
Hi,
Currently as in PG 9.4, 9.5 the order of the statements in the script
produced by pg_dump is uncertain even for the same versions of the
databases and pg_dump.
One database may script grants like
REVOKE ALL ON TABLE contracttype FROM PUBLIC;
REVOKE ALL ON TABLE contracttype FROM madmin;
G
21 matches
Mail list logo
