Re: Dumping an Extension's Script

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Dumping an Extension's Script
Дата
Msg-id m24nk0axcj.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Dumping an Extension's Script  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Dumping an Extension's Script  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, with the design you have proposed, unless you have access to the
> filesystem, it ain't gonna work.  And if you have access to the
> filesystem, then this whole discussion is moot.

I did mention that this version of the patch is only ready to host the
current design talk we have now. I intend to amend it with some inline
ALTER EXTENSION facility.

In the worked out example you gave in another mail of this thread, you
would have to remove any explicit ALTER EXTENSION … ADD … of course, as
in a classic script here.

You would have to fill in both the current and next version of the
extension I guess, as a defensive check, too.

> That doesn't impress me in the slightest.  Suppose you have two
> identically configured machines A and B on which you install hstore
> (from the filesystem) and a hypothetical extension istore (via the
> inline extension mechanism).  Now, you take regular backups of machine
> A, and one day it dies, so you want to restore onto machine B.  Well,
> if you didn't dump with --extension-script, then you've got an
> incomplete backup, so you are hosed.  And if you did dump with

You didn't ever restore your backup? So you didn't know for sure you had
one. More seriously…

> --extension-script, then you're OK in that scenario, but the wheels
> come off if you try to dump and restore onto machine C, which is
> running a newer version of PostgreSQL with an updated hstore.  To do
> it right, you have to remember which extensions you installed which
> way and dump exactly the right thing for each one.  That can't be
> good.

In the patch we're talking about, the --extension-script is an
accumulative option that needs an argument, so you do
  pg_dump --extension-script istore --extension-script foo

or if you're into short options
  pg_dump -X istore -X foo -X bar

I'm not saying that design is perfect nor definitive, it's just what
happens to be in the patch, and it allows you to solve your problem. We
could default the --extension-script to any installed extension for
which we don't have a control file?

> Like Andres, I'd like to see a reference to the thread where we
> supposedly had consensus on this behavior.  I don't really recall us
> achieving consensus on anything, but if we did I have a hard time
> believing it was this.

What I remember about the "consensus" from last year is:
- http://archives.postgresql.org/pgsql-hackers/2012-01/msg01307.php
- inline and file based extensions must be the same beast once in the  database
- pg_dump options should work the same against either kind
- it all boils down to designing a consistent dump behavior

Which is the angle I've been working on reaching this round. The other
thing we said is more about how to get the dump's content, and I
realised that it could be so much simpler than relying on any file
anywhere: pg_extension and pg_depend have all the information we need.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TABLE ... NOREWRITE option
Следующее
От: "David Rowley"
Дата:
Сообщение: Functional dependency in GROUP BY through JOINs