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
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
Hi,
David E. Wheeler da...@kineticode.com 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
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
David E. Wheeler da...@kineticode.com 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
On Jul 23, 2009, at 2:44 AM, David E. Wheeler da...@kineticode.com
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
Robert Haas robertmh...@gmail.com writes:
On Jul 23, 2009, at 2:44 AM, David E. Wheeler da...@kineticode.com
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
On Jul 23, 2009, at 2:11, Dimitri Fontaine dfonta...@hi-media.com
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
On Jul 23, 2009, at 4:08, Robert Haas robertmh...@gmail.com 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
David E. Wheeler da...@kineticode.com 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
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
On Thu, Jul 23, 2009 at 11:05 AM, David E. Wheelerda...@kineticode.com wrote:
On Jul 23, 2009, at 4:08, Robert Haas robertmh...@gmail.com 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
Hi,
The same mail as before in a new thread, per Robert comment. Including
the body rather than an archive link for various reasons, including
making it easy to comment here rather than there.
Le 22 juil. 09 à 02:56, Robert Haas a écrit :
On Tue, Jul 21, 2009 at 7:25 PM, Tom
On Tue, Jul 21, 2009 at 8:56 PM, Robert Haasrobertmh...@gmail.com 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
14 matches
Mail list logo
