Re: dealing with extension dependencies that aren't quite 'e'

Поиск
Список
Период
Сортировка
От Abhijit Menon-Sen
Тема Re: dealing with extension dependencies that aren't quite 'e'
Дата
Msg-id 20160301012745.GA11489@toroid.org
обсуждение исходный текст
Ответ на Re: dealing with extension dependencies that aren't quite 'e'  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Ответы Re: dealing with extension dependencies that aren't quite 'e'  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: dealing with extension dependencies that aren't quite 'e'  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
At 2016-01-18 11:08:19 +0530, ams@2ndQuadrant.com wrote:
>
> I'm proposing to address a part of that problem by allowing extension
> dependencies to be explicitly declared for functions and objects
> created either by a user or dynamically by the extension itself—things
> that need the extension to function, but aren't a part of it.

I didn't hear any further suggestions, so here's a patch for discussion.

1. This adds the 'x'/DEPENDENCY_AUTO_EXTENSION type.
2. This adds an 'ALTER FUNCTION … ADD DEPENDENT FUNCTION …' command.

I split up the two because we may want the new dependency type without
going to the trouble of adding a new command. Maybe extension authors
should just insert an 'x' row into pg_depend directly?

I was inclined to implement it using ALTER FUNCTION, but AlterFunction()
is focused on altering the pg_proc entry for a function, so the new code
didn't fit. Ultimately, ExecAlterExtensionContentsStmt() was the closest
match, so that's where I did it.

Comments welcome. I'll add this patch to the CF.

-- Abhijit

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: create opclass documentation outdated
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Proposal: "Causal reads" mode for load balancing reads without stale data