Re: Dumping an Extension's Script

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Dumping an Extension's Script
Дата
Msg-id 20121205181319.GF27424@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Dumping an Extension's Script  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Dumping an Extension's Script
Список pgsql-hackers
On 2012-12-05 12:55:42 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2012-12-05 19:13:10 +0200, Heikki Linnakangas wrote:
> >> And I still don't understand why pg_dump needs to know about any of this...
>
> > Extensions should be fully per-database and we want pg_dump backups to
> > be restorable into another database/clusters/servers.
>
> Wait a minute.  I haven't bought into either of those statements, and
> most particularly not the first one.

Ok.

> Upthread, Dimitri claimed that he wasn't creating two different kinds of
> extensions with this patch, but the more I read about it the more it
> seems that he *is* making a fundamentally different kind of animal.
> And I don't think it's necessarily a good idea, especially not if we
> still call it an extension.

I have to admit I haven't read the whole discussion about this. And I
also have to say that I have no idea yet whether I like the current
implementation because I haven't looked at it yet. I just wanted to give
input to the separate problems Heikki listed. Because I wished for
something roughly like this for years...

To me it seems to be sensible that extensions which are preinstalled on
the system are global and extensions which a single user inside a single
database created are per database.
Imo that doesn't make them all that fundamentally different.

> I kind of like Heikki's idea of leaving CREATE EXTENSION alone and
> inventing a separate "UPLOAD EXTENSION" operation, but there's a problem
> with that: in many, probably most, installations, the server does not
> and should not have permission to scribble on the directories where the
> extension scripts are stored.  Possibly we could circumvent that by
> creating an auxiliary extensions directory under $PGDATA.  (But then
> it starts to seem like pg_dumpall --- not pg_dump --- ought to include
> those files in its output...)

UPLOAD EXTENSION seems to be a good idea.

But I really really would like them to go to a per-database directory
not a per-cluster one. Otherwise the coordination between different
database "owners" inside a cluster will get really hairy. I want to be
able to install different versions of an application into different
databases.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ... NOREWRITE option
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Dumping an Extension's Script