Re: ALTER EXTENSION .. ADD/DROP weirdness
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-10-12T21:15:50Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rethink behavior of CREATE OR REPLACE during CREATE EXTENSION.
- 988cccc620dd 9.2.0 cited
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The underlying issue here is whether objects dependent on an extension >> member should have direct dependencies on the extension too, and if not, >> how do we prevent that? The recordDependencyOnCurrentExtension calls >> don't have enough information to know what to do, I think. > After looking at this code, it seems that we've generally made that > the caller's problem - e.g. in heap_create_with_catalog(), we skip > recordDependencyOnCurrentExtension() if we're dealing with a composite > type. So I think the fix here is just to move the > recordDependencyOnCurrentExtension() call in pg_type.c inside the > if-block that precedes it, as in the attached patch. Hmm. I'm afraid that's going to break something, because I had had it like that originally and changed it in commit 988cccc620dd8c16d77f88ede167b22056176324. However, I'm not quite sure *what* it will break, because it seems like in general extension dependencies ought to act pretty nearly like owner dependencies. In a quick look, this seems to be the only place where we're doing it differently (without a clear reason) for recordDependencyOnOwner and recordDependencyOnCurrentExtension. Let me poke at it a bit more. The proposed patch is a bit short on comment fixes, anyway. regards, tom lane