Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-16 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: [ scratches head ... ] Why is your version generating so many unnecessary @extschema@ uses? I just ran create table tomlist as select your query and create table dimlist as select my query, then: dim=# select * from tomlist except select * from dimlist;

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-15 Thread Tom Lane
I wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: I think you'd be interested into this reworked SQL query. It should be providing exactly the script file you need as an upgrade from unpackaged. This seems overly complicated. I have a version of it that I'll publish as soon as I've

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-15 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Just for the archives' sake: the '@extschema@' business did turn out to be important, at least for tsearch2 where it's necessary to distinguish the objects it's dealing with from similarly-named objects in pg_catalog. So this is what I used to generate the

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-15 Thread Andrew Dunstan
On 02/15/2011 04:49 PM, Dimitri Fontaine wrote: Ah well sed makes it simpler to read, but it won't be usable in windows. You can make perl do the same stuff (and perl has psed anyway), and perl is required for MSVC builds. cheers andrew -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-15 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Do we want to add such a query in the docs to help pgfoundry authors to write their own 'from unpackaged' scripts? [ scratches head ... ] Why is your version generating so many unnecessary @extschema@ uses? regards, tom

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Also, I've been looking at the pg_available_extensions issue a bit. I don't yet have a proposal for exactly how we ought to redefine it, but I did notice that the existing code is terribly confused by

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Thinking about this some more ... it seems like we now need two separate views, because there is some information that could change per-version, and some that really only makes sense at the per-extension level. Makes sense. For instance, we could have

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: and pg_available_extension_versions that produces a row per install script, with columns name version ((name, version) is primary key) comment requires relocatable schema where

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: I intentionally left out columns that seem like extension implementation details rather than things users of the extension need to know. Hence, no directory, encoding, or module_pathname. There's no fundamental reason not to include these, I guess,

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: [ about omitting rows for which there is no update path ] Yeah, possibly. I'm a bit concerned about cases where the author meant to provide an update path and forgot: it would be fairly obvious in this

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: I don't really think that's a behavior we want to encourage. ISTM the cases that are going to be trouble are paths you failed to think about, and therefore what you want to do is look over the whole output set to see if there are any surprising paths...

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: My take here is to way that in this case, the current (9.1) way to deal with the situation is to have multiple extensions when you have multiple shlibs. After all we know that multiple extensions from the same Makefile works, thanks to contrib/spi (I mean

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: But contrib/spi is exactly the case where it *won't* work. We need to somehow figure out that $libdir/autoinc is what to substitute in autoinc-1.0.sql, $libdir/insert_username in insert_username-1.0.sql, etc.

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Or are you suggesting substituting for MODULE_PATHNAME during CREATE EXTENSION, and not during make at all? That would work I guess. That's my idea, sorry not having made it clear enough. We have $libdir which is expanded server-side AFAIUI, I though we

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: I'm hesitant to have any substitutions that happen unconditionally, but we could add a control parameter like module_pathname = '$libdir/hstore' and then things would be pretty clean. Ok. Maybe the simpler

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: I think it's better to keep it working as a textual substitution. That poses the least risk of breaking scripts that work today --- who's to say that somebody might not be relying on the substitution happening someplace else than CREATE FUNCTION's shlib

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: I think it's better to keep it working as a textual substitution. That poses the least risk of breaking scripts that work today --- who's to say that somebody might not be relying on the substitution happening

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Tom Lane t...@sss.pgh.pa.us writes: I think it's better to keep it working as a textual substitution. Thinking about this some more, it has the advantage that the effects of the control file settings are kept within the script file processing and pg_extension

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: OK, so with that, attached is an example of the complete conversion diff for a contrib module (hstore in particular). Although git status I see you're not using the @extschema@ placeholder in the upgrade

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Yes, it should be unnecessary given the search_path setup done by execute_extension_script(). Also, I think that a relocatable extension's script should not be subject to @extschema@ substitution, no matter what. Oh I'm just realizing that my reasoning

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread David E. Wheeler
On Feb 13, 2011, at 11:34 AM, Tom Lane wrote: OK, so with that, attached is an example of the complete conversion diff for a contrib module (hstore in particular). Although git status reports hstore--1.0.sql as being a rename of hstore.sql.in, git diff doesn't seem to be exceedingly bright

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: I sure would like it if the install script with no version in it corresponded to the latest version. Otherwise, one must rename the file every time one does a release. And as you're noting, you lose Git history that way. (1) git does know it's a

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread David E. Wheeler
On Feb 13, 2011, at 4:46 PM, Tom Lane wrote: I sure would like it if the install script with no version in it corresponded to the latest version. Otherwise, one must rename the file every time one does a release. And as you're noting, you lose Git history that way. (1) git does know

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Feb 13, 2011, at 4:46 PM, Tom Lane wrote: (2) I think that the normal use-case would not involve removing the old file, so this is moot anyhow. Oh. So one normally will ship, for an extension foo, only foo.sql and any necssary upgrade

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread David E. Wheeler
On Feb 13, 2011, at 4:59 PM, Tom Lane wrote: I think after a couple of releases you'd be shipping something like foo--1.0.sql foo--1.1.sql foo--1.0--1.1.sql foo--2.0.sql foo--1.1--2.0.sql and it'll soon get to be a mess if your SCM doesn't clearly

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-13 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Feb 13, 2011, at 4:59 PM, Tom Lane wrote: I suppose if you really wanted foo.sql to always be the head version, you could do something like cp foo.sql foo--$VERSION.sql as part of the build process in the Makefile. That would be okay. Is

[HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Tom Lane
I've run into a small infelicity that was introduced by our recent round of redesign of the extensions feature. Specifically, if we have an installation script that is named like hstore-1.0.sql.in, then what pgxs.mk will substitute for MODULE_PATHNAME in it is $libdir/hstore-1.0 ... not exactly

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: pgxs.mk will substitute for MODULE_PATHNAME in it is $libdir/hstore-1.0 ... not exactly what's wanted. This is because the transformation rule depends on $*, ie the base name of the input file. [...] On balance #3 seems the least bad, but I wonder if anyone

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: pgxs.mk will substitute for MODULE_PATHNAME in it is $libdir/hstore-1.0 ... not exactly what's wanted. This is because the transformation rule depends on $*, ie the base name of the input file. A though that

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Right, the basic difficulty here is exactly that in a Makefile that's building multiple shlibs, there is no easy way to decide which shlibs go with which sql scripts. The existing implementation essentially

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread David E. Wheeler
On Feb 12, 2011, at 2:29 PM, Tom Lane wrote: I did think of another idea besides forbidding dash in extension names: what if we use double dash as the name/version separator, ie the naming conventions are like extension--version.control extension--version.sql

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Feb 12, 2011, at 2:29 PM, Tom Lane wrote: I did think of another idea besides forbidding dash in extension names: what if we use double dash as the name/version separator, +1 You might even consider mandating a double-dash between versions, so

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread David E. Wheeler
On Feb 12, 2011, at 3:12 PM, Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: On Feb 12, 2011, at 2:29 PM, Tom Lane wrote: I did think of another idea besides forbidding dash in extension names: what if we use double dash as the name/version separator, +1 You might even

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Feb 12, 2011, at 3:12 PM, Tom Lane wrote: Hm. I think we'd still have to disallow dash as the first or last character in a version name to make that unambiguous. Not sure it's worth the trouble. How likely is *that*? Not very, but the rules

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread David E. Wheeler
On Feb 12, 2011, at 3:37 PM, Tom Lane wrote: How likely is *that*? Not very, but the rules are getting a bit complicated ... Doesn't seem complicated to me: 1. Use -- to separate extension name, old version, new version 2. Don't use - at the beginning or end of name or version number 3.

Re: [HACKERS] Extensions vs PGXS' MODULE_PATHNAME handling

2011-02-12 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes: Right, the basic difficulty here is exactly that in a Makefile that's building multiple shlibs, there is no easy way to decide which shlibs go with which sql scripts. The existing implementation essentially relies on the base name of the sql script matching