Shared dependencies

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Shared dependencies
Дата
Msg-id 20041028043031.GA9767@dcc.uchile.cl
обсуждение исходный текст
Ответы Re: Shared dependencies  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список pgsql-hackers
Hackers,

I'm currently playing with implementing a "shared dependency" catalog,
to keep track of objects pointing to global objects, currently users and
tablespaces.  So it is forbidden to drop a user that owns tables (or
whatever objects) on other databases.

So far, it works nicely; it lists objects that depend on whatever user/
tablespace one is deleting and then aborts the deletion.  Changing the
owner or tablespace of an object works as expected.

To this end, I have created a pg_sdepend shared catalog, very similar to
pg_depend.  Both users and tablespaces are kept track of there.  That
poses a problem, because users are identified internally using an AclId,
while tablespaces use an Oid.  Most likely those should not be put on
the same column; it works now, but it can break at any time.

So the first obvious question: should I create two separate catalogs,
one for users and other for tablespaces?


The other obvious question is whether we should keep track of only owner
of objects, or also users that happen to be listed in their Acl.  It
would be good to have all the info, but I wonder this won't make the
catalog too bloated.

(The other global objects are currently databases and groups, which
don't have objects depend on them, so there's nothing to record.  If and
when someone implements SQL roles, there may be something to consider
here.  Of course, if it's decided that's a good idea to record Acls,
then groups will have to be included too.)


Comments, opinions and ideas are welcome.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El día que dejes de cambiar dejarás de vivir"



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

Предыдущее
От: Kevin Brown
Дата:
Сообщение: Re: [PATCHES] ARC Memory Usage analysis
Следующее
От: Tom Lane
Дата:
Сообщение: pg_get_serial_sequence is inconsistent