Robert Haas wrote:
I think the key to getting this done is
to keep the design as simple as possible and to avoid entanglements
with other features that may need to be designed independently and
first.
I think the key to getting this done is to define project purpose and
requirements before doi
Hello
attention, MODULE is ANSI SQL keyword, and modules are class from ANSI SQL.
::=
CREATE MODULE
[ ]
[ ] [ ]
[ ... ]
...
END MODULE
::=
NAMES ARE
::=
SCHEMA
::=
::=
::=
Regards
Pavel Stehule
2009/3/23 Tom Lane :
> Robert Haas writes:
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> A defining SQL script is the way to go.
> But I disagree with this, for the simple reason that we don't have
> anything like enough flexibility in the form of conditional DDL or
> error handling, when working in pure SQL without any proce
> "Tom" == Tom Lane writes:
Tom> I think the way most people are envisioning this is that a
Tom> module is a set of SQL objects (functions, types, tables,
Tom> whatever). Whether any of those are C functions in one or more
Tom> underlying .so files is not really particularly relevant to
Le 23 mars 09 à 20:33, Robert Haas a écrit :
It may well be that the table has data in it that was inserted after
module creation time, and the user may want it preserved with the
upgrade, but there's really no way to even begin to guess what the
user had in mind here.
Exactly, we're not in the
On Mon, Mar 23, 2009 at 7:46 AM, Dimitri Fontaine
wrote:
> On Monday 23 March 2009 12:34:31 Robert Haas wrote:
>> That might not be the only time you ever want to create dependencies
>> on the module object. What if the module wants to create an
>> additional table, view, etc. at some later time,
On Monday 23 March 2009 15:43:04 Tom Lane wrote:
> I think the way most people are envisioning this is that a module is a
> set of SQL objects (functions, types, tables, whatever). Whether any
> of those are C functions in one or more underlying .so files is not
> really particularly relevant to t
Dimitri Fontaine writes:
> On Sunday 22 March 2009 22:46:20 Tom Lane wrote:
>> You really haven't convinced me that this is anything but
>> overcomplication.
> Thinking about it some more what could be convincing is that an extension
> could be made of only SQL, with no module (.so) (I have a ca
On Monday 23 March 2009 12:34:31 Robert Haas wrote:
> That might not be the only time you ever want to create dependencies
> on the module object. What if the module wants to create an
> additional table, view, etc. at some later time, following the load?
> I'm not sure whether there's a use case
On Sun, Mar 22, 2009 at 11:26 PM, Greg Stark
wrote:
> Why do you need any explicit syntax? If the database is loading an SQL file
> as a result of a LOAD MODULE command wouldn't it know to set whatever
> internal state it needs to remember that?
That might not be the only time you ever want to cr
On Monday 23 March 2009 04:05:04 Andrew Gierth wrote:
> Dimitri> Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ?
> Yes, I left a short note on its discussion page a while ago :-)
Hehe... I'll answer here, as it's a more opened forum it seems...
Schemas vs Extensions (or modules,
On Sunday 22 March 2009 22:46:20 Tom Lane wrote:
> You really haven't convinced me that this is anything but
> overcomplication.
Thinking about it some more what could be convincing is that an extension
could be made of only SQL, with no module (.so) (I have a case here).
If a single .sql file c
Why do you need any explicit syntax? If the database is loading an SQL
file as a result of a LOAD MODULE command wouldn't it know to set
whatever internal state it needs to remember that?
--
Greg
On 22 Mar 2009, at 23:11, Andrew Gierth
wrote:
"Tom" == Tom Lane writes:
Tom> I doub
> "Tom" == Tom Lane writes:
Tom> I doubt that we want to decorate every CREATE statement we've
Tom> got with an optional MODULE clause; to name just one objection,
Tom> it'd probably be impossible to do so without making MODULE a
Tom> fully reserved word.
Tom> What was discussed in the
> "Dimitri" == Dimitri Fontaine writes:
Dimitri> Hi,
Dimitri> Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :)
Yes, I left a short note on its discussion page a while ago :-)
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
> "Dimitri" == Dimitri Fontaine writes:
>> Partly that's based on the relative inflexibility of the
>> search_path setting; it's hard to modify the search_path without
>> completely replacing it, so knowledge of the "default" search path
>> ends up being propagated to a lot of places.
D
> "Alvaro" == Alvaro Herrera writes:
>> I've been thinking about this, and my conclusion is that schemas
>> as they currently exist are the wrong tool for making
>> modules/packages.
Alvaro> This has been discussed at length previously, and we even had
Alvaro> an incomplete but substant
On Sun, Mar 22, 2009 at 10:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I suspect that it's going to boil down to running a
>> SQL script, which will need to somehow get that module installed. To
>> make that work, I think we need "CREATE MODULE foo" and then "CREATE
>> ... MODULE foo".
Robert Haas writes:
> ... I suspect that it's going to boil down to running a
> SQL script, which will need to somehow get that module installed. To
> make that work, I think we need "CREATE MODULE foo" and then "CREATE
> ... MODULE foo". So the SQL script will
> create the module and then cre
On Sun, Mar 22, 2009 at 7:54 AM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
>
> >> I'm hesitant to do that when we don't yet have either a design or
> >> a migration plan for the module facility. We might find we'd shot
> >> ourselves in the foot, or at least complicated the
On Sun, Mar 22, 2009 at 10:46 PM, Tom Lane wrote:
> There might (or might not) be some use-case
> for being able to declare that module A depends on module B,
Typically, earthdistance requires cube so the module dependency is
already something that might be useful. But as you said, it doesn't
req
Dimitri Fontaine writes:
> Le 22 mars 09 à 22:05, Tom Lane a écrit :
>> This seems drastically overengineered. What do we need two levels of
>> objects for?
> We need to be able to refer (pg_depend) to (system level) modules.
> Any given extension may depend on more than one module.
You really
Le 22 mars 09 à 22:05, Tom Lane a écrit :
This seems drastically overengineered. What do we need two levels of
objects for?
We need to be able to refer (pg_depend) to (system level) modules.
Any given extension may depend on more than one module.
What did I overlook?
--
dim
--
Sent via pg
Dimitri Fontaine writes:
> He also worked out some OS level tools for module handling, but I
> think I'd prefer to have another notion in between, the extension.
> The extension would be a new SQL object referring to zero, one or more
> modules and one or more SQL scripts creating new SQL obj
Hi,
Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :)
Le 22 mars 09 à 14:29, Dave Page a écrit :
- want to be able to do INSTALL PACKAGE foo; without needing to
mess with .sql files. This might default to looking for
$libdir/foo.so, or there might be a mechanism to reg
Hi,
Le 22 mars 09 à 12:42, Andrew Gierth a écrit :
Tom> I'm hesitant to do that when we don't yet have either a design
Tom> or a migration plan for the module facility. We might find we'd
Tom> shot ourselves in the foot, or at least complicated the
Tom> migration situation unduly.
I've been th
Dave Page wrote:
I think using PACKAGE is a bad idea as it'll confuse people used to
Oracle. MODULE perhaps?
Right. We debated this extensively in the past. Module was the consensus
name.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Andrew Gierth wrote:
> I've been thinking about this, and my conclusion is that schemas as
> they currently exist are the wrong tool for making modules/packages.
This has been discussed at length previously, and we even had an
incomplete but substantive patch posted. Did you review that? Some o
On Sun, Mar 22, 2009 at 11:54 AM, Andrew Gierth
wrote:
> - want to be able to do INSTALL PACKAGE foo; without needing to
> mess with .sql files. This might default to looking for
> $libdir/foo.so, or there might be a mechanism to register packages
> globally or locally.
>
> - want to b
> "Robert" == Robert Haas writes:
>> I'm hesitant to do that when we don't yet have either a design or
>> a migration plan for the module facility. We might find we'd shot
>> ourselves in the foot, or at least complicated the migration
>> situation unduly.
Robert> I think there have be
> "Tom" == Tom Lane writes:
> Robert Treat writes:
>> We've been talking about this magical "proper module facility" for
>> a few releases now... are we still opposed to putting contrib
>> modules in thier own schema?
Tom> I'm hesitant to do that when we don't yet have either a design
> "Tom" == Tom Lane writes:
Tom> I agree that this wasn't an amazingly good choice, but I think
Tom> there's no real risk of name collisions because fmgr only
Tom> searches for such names within the particular .so.
>> Oh, if only life were so simple.
Tom> I think you are missing the po
On Sat, Mar 21, 2009 at 9:49 PM, Tom Lane wrote:
> Robert Treat writes:
>> We've been talking about this magical "proper module facility" for a few
>> releases now... are we still opposed to putting contrib modules in thier own
>> schema?
>
> I'm hesitant to do that when we don't yet have either
Robert Treat writes:
> We've been talking about this magical "proper module facility" for a few
> releases now... are we still opposed to putting contrib modules in thier own
> schema?
I'm hesitant to do that when we don't yet have either a design or a
migration plan for the module facility. W
On Saturday 21 March 2009 12:27:27 Tom Lane wrote:
> Andrew Gierth writes:
> > "Tom" == Tom Lane writes:
> > Tom> I agree that this wasn't an amazingly good choice, but I think
> > Tom> there's no real risk of name collisions because fmgr only
> > Tom> searches for such names within the partic
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I agree that this wasn't an amazingly good choice, but I think
> Tom> there's no real risk of name collisions because fmgr only
> Tom> searches for such names within the particular .so.
> Oh, if only life were so simple.
I think you ar
On Sat, Mar 21, 2009 at 01:05:35PM +, Andrew Gierth wrote:
> (Perhaps we should be linking contrib and pgxs modules with -Bsymbolic
> on those platforms where it matters?)
Another possibility is to use the visibility attributes such as those
provided in GCC. Maybe the version1 declarion of a f
> "Tom" == Tom Lane writes:
Tom> I agree that this wasn't an amazingly good choice, but I think
Tom> there's no real risk of name collisions because fmgr only
Tom> searches for such names within the particular .so.
Oh, if only life were so simple.
Consider two modules mod1 (source files
> "Simon" == Simon Riggs writes:
> On Sat, 2009-03-21 at 01:57 +, Andrew Gierth wrote:
>> Note that I'm talking here about the names of the C functions, not
>> the SQL names.
>>
>> The existing hstore has some very dubious choices of function names
>> (for non-static functions) in
On Sat, 2009-03-21 at 01:57 +, Andrew Gierth wrote:
> Note that I'm talking here about the names of the C functions, not
> the SQL names.
>
> The existing hstore has some very dubious choices of function names
> (for non-static functions) in the C code; functions like each(),
> delete(), fetc
Andrew Gierth writes:
> Note that I'm talking here about the names of the C functions, not
> the SQL names.
> The existing hstore has some very dubious choices of function names
> (for non-static functions) in the C code; functions like each(),
> delete(), fetchval(), defined(), tconvert(), etc.
On Fri, Mar 20, 2009 at 9:57 PM, Andrew Gierth
wrote:
> Note that I'm talking here about the names of the C functions, not
> the SQL names.
>
> The existing hstore has some very dubious choices of function names
> (for non-static functions) in the C code; functions like each(),
> delete(), fetchva
Note that I'm talking here about the names of the C functions, not
the SQL names.
The existing hstore has some very dubious choices of function names
(for non-static functions) in the C code; functions like each(),
delete(), fetchval(), defined(), tconvert(), etc. which all look to me
like prime c
43 matches
Mail list logo
