Re: SQL objects UNITs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SQL objects UNITs
Дата
Msg-id 23579.1387682856@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SQL objects UNITs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Dec 21, 2013 at 12:10 PM, Dimitri Fontaine
> <dimitri@2ndquadrant.fr> wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>>> That said, I'm starting to wonder about a few
>>> different options that might be handy- having the extension be dumpable
>>> (or maybe an option to pg_dump to dump them from the DB, or not), and
>>> perhaps an option to have the version # included in the dump (or an
>>> option to exclude it, such as when run by pg_upgrade..?).  Perhaps
>>> similar things for pg_restore.
>>> 
>>> In any case, this is certainly the way I had been hoping the discussion
>>> would go..
>> 
>> http://www.postgresql.org/message-id/18778.1354753982@sss.pgh.pa.us

> Fortunately, nobody's proposing that exact design, and I think there
> are more recent emails where Tom expressed at least some support for
> the idea of installing an extension purely via SQL, and in fact backed
> the idea of being able to dump-and-restore the extension members as
> superior to storing blobs in the catalog.

AFAICT, what I was complaining about there was the idea that the
per-extension behavior had to be specified via switches to pg_dump
in order to get a valid dump.  That doesn't seem too workable ---
you think your nightly backup script will know that?  But the idea that
it's an alterable property of each extension, *stored in the database*,
does not fall foul of that complaint.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SQL objects UNITs
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: ISN extension bug? (with patch)