Tom Lane writes:
> I see no
> argument whatsoever why we should lock down extensions and only extensions
> against this risk.
Spelled this way I can only agree :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mai
Dimitri Fontaine writes:
> Tom Lane writes:
>> If you're worried about that, then it's questionable whether ALTER
>> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
>> to think that an extension is more fragile for this purpose than any
>> other random SQL dependencies. Al
Tom Lane writes:
> If you're worried about that, then it's questionable whether ALTER
> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
> to think that an extension is more fragile for this purpose than any
> other random SQL dependencies. Also, an extension being relocatab
On Feb 7, 2011, at 10:23 AM, Tom Lane wrote:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something
Dimitri Fontaine writes:
> That said, we should do something about ALTER EXTENSION SET SCHEMA and
> the relocatable property. I'm thinking that an extension stops being
> relocatable as soon as any of its reverse dependencies (all the tree) is
> not relocatable.
If you're worried about that, the
Tom Lane writes:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something like
>
> requires = '
I wrote:
> ... So where I think we're going to end up
> is adding a clause along the line of "USING list-of-extension-names"
> to CREATE EXTENSION, storing those dependencies explicitly, and having
> the CREATE EXTENSION code set search_path to the target schema followed
> by the target schema(s) o
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
BTW, on trying this I notic
"David E. Wheeler" writes:
> On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
>> Interesting point. It's all right at the moment because I tweaked
>> pg_dump_sort.c so that procedural languages are dumped before modules.
>> But maybe we should convert the PLs to modules.
> s/modules/extensions/?
Yea
On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
> Interesting point. It's all right at the moment because I tweaked
> pg_dump_sort.c so that procedural languages are dumped before modules.
> But maybe we should convert the PLs to modules.
s/modules/extensions/?
David
--
Sent via pgsql-hackers ma
On Feb 7, 2011, at 9:20 AM, Dimitri Fontaine wrote:
> Also, I didn't bite this bullet, but maybe we should provide core PLs as
> extension. Then CREATE LANGUAGE would maybe get deprecated and only
> valid when used in an extension's script — or the next patch (UPGRADE)
> will take care of create
Dimitri Fontaine writes:
> Tom Lane writes:
>> Quite aside from search path, cross-extension dependencies simply aren't
>> going to work unless pg_dump knows about them so it can load the
>> extensions in the right order. I had forgotten about the earthdistance
>> case, but given that I think we
Tom Lane writes:
> No, I've hacked the code enough already that merging would be painful.
> I'll keep working on it.
I supposed so much, but got to ask :)
> Oh, duh, I'd forgotten about the OverrideSearchPath usage. So never
> mind the above claim. But I still think it'd be a good idea to ensu
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
> Would it help that I prep
Tom Lane writes:
> One is ownership. Since we don't record the identity of the user who
> created an extension, there's no way for pg_dump to ensure that it's
> recreated by the same user. I think we'll regret that in future even
> if you don't think it's problematic today. In particular, I for
There are some things that the current extensions patch leaves
indeterminate during a dump and reload cycle, which strikes me
as a bad thing.
One is ownership. Since we don't record the identity of the user who
created an extension, there's no way for pg_dump to ensure that it's
recreated by the
16 matches
Mail list logo
