On 5/31/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> >>> Could you serve this as special docstring instead? Eg:
> >>> PG_MODULE(foomodule)
>
> I have no objection to that, and see no real implementation problem with
> it: we just add a "const char *" field to the magic block. The other
> stuff seems too blue-sky, and I'm not even sure that it's the right
> direction to proceed in.

It was not blue-sky, it was handwaving

> Marko seems to be envisioning a future where
> an extension module is this binary blob with install/deinstall/etc code
> all hardwired into it. I don't like that a bit. I think the current
> scheme with separate SQL scripts is a *good* thing, because it makes it
> a lot easier for users to tweak the SQL definitions, eg, install the
> functions into a non-default schema. Also, I don't have a problem
> imagining extension modules that contain no C code, just PL functions
> --- so the SQL script needs to be considered the primary piece of the
> module, not the shared library.

I'll later post a list of ideas that we can hopefully agree on
and discuss them further.

> Is it worth adding a module name to the magic block, or should we just
> leave well enough alone? It's certainly not something foreseen as part
> of the purpose of that block. In the absence of some fairly concrete
> ideas what to do with it, I'm probably going to vote keep-it-simple.

Yes, if we want to keep separate SQL for modules then
putting stuff into .so is pointless.

--
marko

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
<snip>
> ... The other
> stuff seems too blue-sky, and I'm not even sure that it's the right
> direction to proceed in. Marko seems to be envisioning a future where
> an extension module is this binary blob with install/deinstall/etc code
> all hardwired into it. I don't like that a bit. I think the current
> scheme with separate SQL scripts is a *good* thing, because it makes it
> a lot easier for users to tweak the SQL definitions, eg, install the
> functions into a non-default schema. Also, I don't have a problem
> imagining extension modules that contain no C code, just PL functions
> --- so the SQL script needs to be considered the primary piece of the
> module, not the shared library.

While you do have a good point about non-binary modules, our module
handling need some help IMHO. For example, the current hack for CREATE
LANGUAGE to fix things caused by old pg_dumps. I think that's the
totally wrong approach long term, I think the pg_dump shouldn't be
including the CREATE LANGUAGE statement at all, but should be saying
something like "INSTALL plpgsql" and pg_restore works out what is
needed for that module.

The above requires getting a few bits straight:

1. When given the name of an external module, you need to be able to
find the SQL commands needed to make it work.

2. You need to be able to tell if something is installed already or
not.

3. You need to be able to uninstall it again. Why do we rely on
hand-written uninstall scripts when we have a perfectly functional
dependancy mechanism that can adequatly track what was added and remove
it again on demand.

With these in place, upgrades across versions of postgres could become
a lot easier. People using tsearch2 now would get only "INSTALL
tsearch2" in their dumps and when they upgrade to 8.2 they get the new
definitions for tsearch using GIN. No old definitions to confuse people
or the database. (Note: I'm not sure if tsearch would be compatable at
the query level, but that's not relevent to the point I'm making).

We could get straight into discussions of mechanism, but it would be
nice to know if people think the above is a worthwhile idea.

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEfgaWIB7bNG8LQkwRArgVAJ4jbHkwEiht2SXJciuUIk lesryBWQCfYgoc
jP2T7X9AKtBHGuU51b+HQvM=
=3li9
-----END PGP SIGNATURE-----

On Wednesday 31 May 2006 13:24, Martijn van Oosterhout wrote:
> On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
> > Is it worth adding a module name to the magic block, or should we just
> > leave well enough alone? It's certainly not something foreseen as part
> > of the purpose of that block. In the absence of some fairly concrete
> > ideas what to do with it, I'm probably going to vote keep-it-simple.
>
> I actually considered it while writing the patch but decided against
> given the general tendancy against putting extra info into the modules
> in general...
>
> Personally I think it's a good idea, except: where is this info going
> to be displayed or used?
>

Marko's suggestion on producing a list of installed modules comes to mind, and
I suspect tools like pgadmin or ppa will want to be able to show this
information.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> Marko's suggestion on producing a list of installed modules comes to mind, and
> I suspect tools like pgadmin or ppa will want to be able to show this
> information.

My request for phpPgAdmin is to somehow be able to check if the .so file
for a module is present.

For instance, I'd like to 'enable slony support' if the slony shared
library is present. PPA's slony support automatically executes the .sql
files, so all I need to know is if the .so is there.

Chris


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Christopher Kings-Lynne <chris.kings-lynne@calorieking.com> writes:
> My request for phpPgAdmin is to somehow be able to check if the .so file
> for a module is present.

> For instance, I'd like to 'enable slony support' if the slony shared
> library is present. PPA's slony support automatically executes the .sql
> files, so all I need to know is if the .so is there.

I really think this is backwards: you should be looking for the .sql
files. Every module will have a .sql file, not every one will need a
..so file. See followup thread in -hackers where we're trying to hash
out design details.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

>> For instance, I'd like to 'enable slony support' if the slony shared
>> library is present. PPA's slony support automatically executes the .sql
>> files, so all I need to know is if the .so is there.
>
> I really think this is backwards: you should be looking for the .sql
> files. Every module will have a .sql file, not every one will need a
> .so file. See followup thread in -hackers where we're trying to hash
> out design details.

Not in this case.

Basically Slony has the concept of installing a node into a server. You
can have multiple ones of them - different schemas. So, I'd like to be
able to detect that the .so is there, and then offer an "install node"
feature where WE execute the SQL on their behalf, with all the
complicated string substitions already done.

The trick is that Slony currently requires you to use a command line
tool to execute these scripts for you.

At the moment, people have to indicate in our config while that Slony is
available, and also point us to where the Slony SQL scripts are located.
We do the rest.

It's not too important, but it's just an idea.

Chris


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Christopher Kings-Lynne <chris.kings-lynne@calorieking.com> writes:
>> I really think this is backwards: you should be looking for the .sql
>> files. Every module will have a .sql file, not every one will need a
>> .so file. See followup thread in -hackers where we're trying to hash
>> out design details.

> Not in this case.

> Basically Slony has the concept of installing a node into a server. You
> can have multiple ones of them - different schemas. So, I'd like to be
> able to detect that the .so is there, and then offer an "install node"
> feature where WE execute the SQL on their behalf, with all the
> complicated string substitions already done.

No, Slony is going to have to adapt to modules, not vice versa. We are
*not* designing the module feature on the assumption that every module
has some C functions at its core. That would be a shameful restriction
of the potential applications.

It might be that some way to parameterize the SQL scripts would be handy
(the question about which schema to install into comes to mind) ... but
that doesn't justify making a .so file the central part of the module
concept.

But again, this is the wrong list. Please contribute to the
"Generalized concept of modules" thread in -hackers.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Thursday 01 June 2006 21:38, Christopher Kings-Lynne wrote:
> > Marko's suggestion on producing a list of installed modules comes to
> > mind, and I suspect tools like pgadmin or ppa will want to be able to
> > show this information.
>
> My request for phpPgAdmin is to somehow be able to check if the .so file
> for a module is present.
>
> For instance, I'd like to 'enable slony support' if the slony shared
> library is present. PPA's slony support automatically executes the .sql
> files, so all I need to know is if the .so is there.
>

While I agree with the above (having that for tsearch2 would be nice too) I
think we ought to keep in mind the idea of sql based modules. Nothing jumps
to mind here ppa wise, but I could see an application looking to see if
mysqlcompat was installed before running if it had a good way to do so.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster