On Thu, Jul 23, 2009 at 11:05 AM, David E. Wheeler wrote:
> On Jul 23, 2009, at 4:08, Robert Haas wrote:
>
>> Yes... but "if" and "just" can paper over a good deal of complexity, and
>> it's not clear to me that there's any compensating advantage.
>
> It seems reasonable not to worry about this is
On Jul 23, 2009, at 8:09 AM, Dimitri Fontaine wrote:
What about embedded calls in, say, plperl functions.
Hence the variable suggestion. In fact, it might go back to the idea
of subschemas, perhaps the name of the extension should be part of the
qualifying? I dunno, I'm just kind of throwi
"David E. Wheeler" writes:
> Part of the behavior of CREATE EXTENSION would be to automatically
> schema-qualify references to objects in the extension. Or perhaps
> extension authors would need to use some sort of variable for the schema
> that would be properly resolved when CREATE EXTENSION i
On Jul 23, 2009, at 4:08, Robert Haas wrote:
Yes... but "if" and "just" can paper over a good deal of complexity,
and it's not clear to me that there's any compensating advantage.
It seems reasonable not to worry about this issue in the first rev, or
at least not to let it stop development
On Jul 23, 2009, at 2:11, Dimitri Fontaine
wrote:
Well the problem with that is if for example I define foo() and bar()
functions in my extension, and the user also has a foo() function in
his
own stuff (possibly lying in public, say).
Now if in my extenion in function bar() I call foo(),
Robert Haas writes:
> On Jul 23, 2009, at 2:44 AM, "David E. Wheeler"
> wrote:
>>
>> Well, it depends. If there could be some sort of defined interface for
>> pg_migrator could call to migrate any data type (this issue applies
>> mainly to types, yes?), then an extension author just needs to im
On Jul 23, 2009, at 2:44 AM, "David E. Wheeler"
wrote:
On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than a kick in the head.
"David E. Wheeler" writes:
> On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:
>> Easy answer for first version: don't allow user to install extension in
>> another place than what we think will better suit him, and that's the
>> new schema pg_extension, which always lies just before pg_catalog
On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:
Easy answer for first version: don't allow user to install extension
in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in
the
search_path.
Well, I
Hi,
"David E. Wheeler" writes:
> On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:
>> - how to give user the ability to install the extension's objects in
>> another schema than the pg_extension default one
>
> And just allow it to take a schema-qualified argument like any other SQL
> command
On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:
Here are from memory the problems we don't have a solution for yet:
- how to give user the ability to install the extension's objects in
another schema than the pg_extension default one
Was that not a part of your original proposal, or th
On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than a kick in the head.
And as long as you're willing to deprecate how far back y
On Tue, Jul 21, 2009 at 8:56 PM, Robert Haas wrote:
> A decent module infrastructure is probably not going to fix this
> problem unless it links with -ldwiw. There are really only two
> options here:
>
> - Keep the old version around for compatibility and add a new version
> that isn't compatible,
13 matches
Mail list logo
