Re: Enhancement request for pg_dump

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Enhancement request for pg_dump
Дата
Msg-id CAKJS1f9c8wjpdonSdepMhuUaLJsGUm=kuyxfQO+f9r=9aRn-Fw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Enhancement request for pg_dump  (Sergei Agalakov <Sergei.Agalakov@getmyle.com>)
Список pgsql-general
On 18 April 2016 at 13:10, Sergei Agalakov <Sergei.Agalakov@getmyle.com> 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 use the third party tools to do it, and don't want any native
> support. If I see any support from other people for this idea then I shall
> go to https://postgresql.uservoice.com/forums/21853-general, but looking on,
> say, "Partitions in Oracle style" that are marked as have been started in
> 2010
> (sure, INHERITANCE is so much Oracle style partitions!) I don't see it to be
> very useful.

I can't particularly vouch for that site, as I've personally never
seen it before, but I'd like to say that you'll probably get along
better if you appeared to have a more optimistic view. If you bothered
to consider the "parallel query option" item listed on that site, and
compared that to the current status of 9.6, you might feel
differently. EDB and others have put lots of work in to parallel query
for 9.6. If your intentions here are to gather support for your cause
then I highly recommend not appearing negative. Keep in mind that
you've not paid some company for a license for PostgreSQL and the
people reading your emails here are most likely not at your beckon
call, and are not here to fulfill all your PostgreSQL wishes.

To me your proposal does seem quite half thought through. Do you
really suppose we just sort the GRANT output and call it done. pg_dump
now has stable output? I think that would barely scratch the surface.
What about COPY output, we'd have to sort that too, and that could be
rather expensive. Now, you could say that we'd just limit this to
schema-only related stuff, and that might be ok, but you'll need to
ensure that everything is addressed and that your now matching output
didn't just occur because all of the planets happened to line up on
the day you ran pg_dump.  You might propose that we could get around
the performance hit of generating a stable output by having an
optional flag to enable this. That would appear to sound ok at my
first thought.   If C is your thing then you could open up pg_dump.c
and have a look around, if not then remaining positive and
constructive, and doing your best not to upset people who's C *is*
their thing is probably a good tactical move here.


В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: How to detoast a column of type BYTEAOID
Следующее
От: Albe Laurenz
Дата:
Сообщение: Re: How to detoast a column of type BYTEAOID