On Sunday 22 September 2013 01:34:53 Peter Eisentraut wrote:
> On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote:
> > I am using approximatively the layout that was proposed here:
> > http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
> > It looks like everything is hard-coded
On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote:
> I am using approximatively the layout that was proposed here:
> http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
> It looks like everything is hard-coded to take the source and the
> gcda, gcno files in the base directory,
Thank you for the tip, its done.
2013/7/26 Robert Haas :
> On Thu, Jul 25, 2013 at 11:07 AM, Ronan Dunklau wrote:
>> Hello.
>>
>> I was having trouble figuring how to use the coverage targets when
>> using an extension.
>> I am using approximatively the layout that was proposed here:
>> http://ww
On Thu, Jul 25, 2013 at 11:07 AM, Ronan Dunklau wrote:
> Hello.
>
> I was having trouble figuring how to use the coverage targets when
> using an extension.
> I am using approximatively the layout that was proposed here:
> http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
> It loo
Please ignore this comment:
> I noticed that make clean leaves gcda and gcov files on the current
> HEAD, and this is no different with the given patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Hello.
I was having trouble figuring how to use the coverage targets when
using an extension.
I am using approximatively the layout that was proposed here:
http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
It looks like everything is hard-coded to take the source and the
gcda, gcn
On Nov 2, 2012, at 7:56 AM, Dimitri Fontaine wrote:
>> I'd also be in favor of adding hooks to generate man pages.
>
> Who still use their local copy of the docs (without search ability)
> anyway? About man pages, I don't know how many DBA are looking there
> when they want to find some document
"David E. Wheeler" writes:
> Put it into the HTML directory
> (share/docs/html/extensions/$extension.html) and inject its name into
> the TOC.
>
> I'd also be in favor of adding hooks to generate man pages.
Who still use their local copy of the docs (without search ability)
anyway? About man page
On Oct 30, 2012, at 2:08 PM, Peter Eisentraut wrote:
>> True, which is why I was thinking of something relatively light-weight
>> and self-contained like sundown.
>
> That's a markdown library, which transforms markdown to HTML, right? So
> what would we do with the HTML?
Put it into the HTML
On Fri, 2012-10-26 at 09:09 -0700, David E. Wheeler wrote:
> On Oct 26, 2012, at 5:27 AM, Peter Eisentraut wrote:
> > The advantage that these programming language ecosystems have is that
> > they can implement the processors for the documentation format in the
> > language itself, so it's easy t
On Oct 26, 2012, at 5:27 AM, Peter Eisentraut wrote:
>
> The advantage that these programming language ecosystems have is that
> they can implement the processors for the documentation format in the
> language itself, so it's easy to recommend or enforce a particular
> system. I don't think we'
On 10/25/12 1:53 PM, David E. Wheeler wrote:
> I'm thinking of Pod as the precedent here, but I think most of the popular
> programming language ecosystems offer something like this (JavaDoc, rdoc,
> etc.).
The advantage that these programming language ecosystems have is that
they can implement
On Oct 25, 2012, at 5:07 PM, Peter Eisentraut wrote:
> I think the emerging standard is to have a README.md (or something
> similar). This gives enough structure and formatting options for most
> extensions.
For PGXN, I have used a README.md for a readme (briefly about the extension,
how to bu
On Thu, 2012-10-25 at 10:31 -0700, David E. Wheeler wrote:
> Any plans to implement a documentation standard for extensions? I would love
> to see `make install` create the necessary man pages and perhaps even HTML
> (with a link added in the proper place). Anyone given this any thought? Dim?
I
On Oct 25, 2012, at 10:42 AM, Simon Riggs wrote:
>> Any plans to implement a documentation standard for extensions? I would love
>> to see `make install` create the necessary man pages and perhaps even HTML
>> (with a link added in the proper place). Anyone given this any thought? Dim?
>
> Isn
On 25 October 2012 19:31, David E. Wheeler wrote:
> Hackers,
>
> Any plans to implement a documentation standard for extensions? I would love
> to see `make install` create the necessary man pages and perhaps even HTML
> (with a link added in the proper place). Anyone given this any thought? Dim
Hackers,
Any plans to implement a documentation standard for extensions? I would love to
see `make install` create the necessary man pages and perhaps even HTML (with a
link added in the proper place). Anyone given this any thought? Dim?
Thanks,
David
--
Sent via pgsql-hackers mailing list (
On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina wrote:
> On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas wrote:>
>> Assuming the command in
>> question can be stuffed inside a function, the most you're gaining is
>> a little notational convenience
>
> I can answer that one (why a full-blown mechanism
On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas wrote:>
> Assuming the command in
> question can be stuffed inside a function, the most you're gaining is
> a little notational convenience
I can answer that one (why a full-blown mechanism for a notational convenience).
It has occurred to me to use t
Robert Haas writes:
> Personally, I hate patches that do more than one thing. For me, the
> time required to verify a patch goes as about O(n^2) in its size.
That's exactly why I'm opening that discussion. The main difference
between the approaches I can take is the time it takes to export each
On Tue, Dec 20, 2011 at 10:01 AM, Dimitri Fontaine
wrote:
> Either I develop them separately, with separate branches derived from
> the master one, or I develop them as a stack, one on top of the other.
> The difference is my ability to provide a patch for one of the features
> that can be applied
Hi,
I've sent a first patch to improve extensions for 9.2, and intend on
sending a few more which I'll briefly present here. The point of this
email is to figure out how to branch the development, as all the patch
are going to conflict somehow (change the same parts of the code).
Either I develop
Magnus Hagander writes:
> Is there any particular reason why we can't/don't auto-create schema
> bar when you run "CREATE EXTENSION foo SCHEMA bar"?
We do it when the schema is given in the control file. I'm not sure off
hand but we maybe only do that when the extension is *not* relocatable.
Th
Magnus Hagander writes:
> Is there any particular reason why we can't/don't auto-create schema
> bar when you run "CREATE EXTENSION foo SCHEMA bar"?
That was considered, and rejected for reasons that I probably don't
recall all of, but I do remember one argument: 99.44% of the time
you want an ex
On Mon, May 16, 2011 at 3:59 AM, Magnus Hagander wrote:
> Is there any particular reason why we can't/don't auto-create schema
> bar when you run "CREATE EXTENSION foo SCHEMA bar"?
OK, I'll ask the obvious question. Should we also auto-create the
schema when a user says CREATE TABLE bar.foo()?
Is there any particular reason why we can't/don't auto-create schema
bar when you run "CREATE EXTENSION foo SCHEMA bar"?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Apr 5, 2011, at 1:59 PM, Aidan Van Dyk wrote:
> Versions are useful for figuring out if I should upgrade packages or
> not. But I believe the extension framework has explicitly made the
> "upgrade" problem a manual one at this point, either taking
> destination versions from the control, or th
On Tue, Apr 5, 2011 at 4:51 PM, David E. Wheeler wrote:
>> Of course, I'ld love for extension in 9.1 to provide a basic
>> provides/features for my extension to give, but if that train has
>> already left the station, I don't have much choice ;-(
>
> Yeah, but the way it is doesn't break the abil
On Apr 5, 2011, at 1:42 PM, Aidan Van Dyk wrote:
> Sure, but if you want, the "feature" you can provide can be something like:
> pgtap-1.0 (or any of pgtap-0.2{0,1,2,3,4}).
>
> And if your package is backwards compatable, it could even provide:
> pgtap-0.25
> pgtap-0.24
> pgtap-0.23
I se
On Tue, Apr 5, 2011 at 4:20 PM, David E. Wheeler wrote:
> On Apr 4, 2011, at 3:57 PM, Tom Lane wrote:
>
>>> I think the general movement is toward *feature* dependancies. So for
>>> intstance, an extension can specify what *feature* it requires, and
>>> difference "versions" of an extension can p
On Apr 4, 2011, at 3:57 PM, Tom Lane wrote:
>> I think the general movement is toward *feature* dependancies. So for
>> intstance, an extension can specify what *feature* it requires, and
>> difference "versions" of an extension can provide different
>> "features".
>
> Right.
Sounds like a book
Aidan Van Dyk writes:
> I think the general movement is toward *feature* dependancies. So for
> intstance, an extension can specify what *feature* it requires, and
> difference "versions" of an extension can provide different
> "features".
That sounds like what Emacs is doing too.
> But checkin
Aidan Van Dyk writes:
> On Mon, Apr 4, 2011 at 6:06 PM, Robert Haas wrote:
>> Oh, really? How can you possibly get by without it? Dependencies of
>> this type are all over the place.
> I think the general movement is toward *feature* dependancies. So for
> intstance, an extension can specify
Robert Haas writes:
> On Mon, Apr 4, 2011 at 5:48 PM, Tom Lane wrote:
>> ... In particular I'm really skeptical of the theory that we need
>> or should want version restrictions in Requires references. The
>> equivalent feature in RPM is deprecated for Fedora/RedHat packaging use,
>> and I see n
On Mon, Apr 4, 2011 at 6:06 PM, Robert Haas wrote:
>> I don't. We deliberately decided *not* to have any wired-in
>> interpretation of extension numbers, and I don't think that decision
>> needs to be reversed. David can choose to enforce something for stuff
>> distributed through PGXN if he wi
On Apr 4, 2011, at 2:48 PM, Tom Lane wrote:
> Once 9.1 is out, it'll probably be too late to dictate any semantics for
> version numbers, because somebody will have done something incompatible
> with it before 9.2 is released. If we are going to try to insist on
> this, now is the time.
Yes, exa
On Mon, Apr 4, 2011 at 5:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 1, 2011 at 11:45 AM, David E. Wheeler
>> wrote:
>>> * I think we're going to need a formal version string spec for extensions.
>
>> I agree.
>
> I don't. We deliberately decided *not* to have any wired-in
> in
Robert Haas writes:
> On Fri, Apr 1, 2011 at 11:45 AM, David E. Wheeler
> wrote:
>> * I think we're going to need a formal version string spec for extensions.
> I agree.
I don't. We deliberately decided *not* to have any wired-in
interpretation of extension numbers, and I don't think that dec
On Fri, Apr 1, 2011 at 11:45 AM, David E. Wheeler wrote:
> But I'm assuming that at some point there's going to be something a bit more
> robust: specifically, requiring a minimum version, perhaps something like:
>
> requires = 'foo 1.0, bar 0.31.4'
Or maybe:
requires = 'foo = 1.0, bar >= 0.
Hackers,
I wanted to get a (ok, not so) quick note in about this before the beta
dropped. I've been thinking about the "requires" parameter on extensions
control files. Right now it just lists the names of extensions that are
required for the extension to run:
requires = 'foo, bar'
But I'
Tom Lane writes:
> The next question is how come this regression test ever worked on that
> platform. The reason is that up till my changes for $SUBJECT, when you
> issued "CREATE LANGUAGE plpython2u" in a database that already had
> plpythonu installed, CREATE LANGUAGE found C functions of the e
Andrew Dunstan writes:
> FYI, I'm working on the MSVC issues.
Ah, great. I was just about to start hacking something together, but
it'd be better for somebody to do it who can test it before committing...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
On 03/05/2011 12:17 PM, Tom Lane wrote:
Dimitri Fontaine writes:
Tom Lane writes:
The only easy fix I can see at the moment is to arbitrarily create two
pg_proc entries --- they can both point at the same C function, but
there need to be two of 'em.
So for 9.1, I think you took the simples
Dimitri Fontaine writes:
> Tom Lane writes:
>> The only easy fix I can see at the moment is to arbitrarily create two
>> pg_proc entries --- they can both point at the same C function, but
>> there need to be two of 'em.
> So for 9.1, I think you took the simplest path available.
It's never tha
Tom Lane writes:
> I can imagine that someplace down the road we might want to allow
> multiple extensions to own the same SQL object; I know that RPMs can
> share ownership of files, for comparison. But today is not that day.
[…]
> Anyone have a different answer?
What could be done is to have a
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> ITYM plperl only, because plpython does not have a trusted variant. But
> there might be another obstacle here: plpython comes in two variants:
> plpython2u and plpython3u, and which one is built depends on the compile
> time configuration. Not sure how t
On 05/03/11 01:58, Tom Lane wrote:
> So while hacking away at the PLs-as-extension changes I ran across an
> unforeseen complication. plperl and plpython use the same C function
> entry points for both their trusted and untrusted variants. This is
> problematic for making them into extensions, si
So while hacking away at the PLs-as-extension changes I ran across an
unforeseen complication. plperl and plpython use the same C function
entry points for both their trusted and untrusted variants. This is
problematic for making them into extensions, since we need the two
language variants to be
Dimitri Fontaine writes:
> Tom Lane 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:
> ...
> No difference on @extschema@ use here
Tom Lane 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;
Dimitri Fontaine 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 lane
--
Sent via pgs
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 (pgsql-h
Tom Lane 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 "unpackaged"
>
I wrote:
> Dimitri Fontaine 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 tested it on all
Tom Lane writes:
> Sure I did: \dx+
And I believe I did test that. Sorry for the noise, really. (shame)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Dimitri Fontaine writes:
> I realize that you didn't keep the \dx behavior I had, that when given
> an extension name it would list all the objects contained in the
> extension.
Sure I did: \dx+
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Tue, Feb 15, 2011 at 11:37 AM, Dimitri Fontaine
wrote:
> Do we want to get that back in, and in which psql command? It could
> well be that having \dx list extension and \dx name list extension's
> objects wasn't the best design around, and it could be that it's not
> useful enough, but I know
Hi,
I realize that you didn't keep the \dx behavior I had, that when given
an extension name it would list all the objects contained in the
extension. Now that's a pretty simple query:
select pg_describe_object(classid, objid, 0)
from pg_depend d
join pg_extension e on d.refclassid =
Tom Lane 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...
Mmm, yes. Ok.
-
Dimitri Fontaine writes:
> Tom Lane 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
>> representation but maybe you could k
Tom Lane 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, although maybe there c
Dimitri Fontaine writes:
> Tom Lane 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 the last four column
Tom Lane 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 pg_available_extens
Dimitri Fontaine writes:
> Tom Lane 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
>> secondary control files: it doesn't real
"David E. Wheeler" 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 $EXTVERSION st
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
"David E. Wheeler" 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 scripts?
I thi
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
"David E. Wheeler" 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 rename, it's jus
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 b
Tom Lane 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 predates the searc
Dimitri Fontaine writes:
> Tom Lane 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
> script. It is intentional?
Yes, i
Tom Lane writes:
>> Tom Lane 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 catalog. The only backend impa
Dimitri Fontaine writes:
> Tom Lane 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 FUNC
Tom Lane 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 string?
Fair enoug
Dimitri Fontaine writes:
> Tom Lane 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 would be to make the current co
Tom Lane 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 would have $shlib
Dimitri Fontaine writes:
> Tom Lane 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.
> Indeed. That's why I'm prop
Tom Lane 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 extension/sp
Tom Lane 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 the base name
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.
"David E. Wheeler" 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 are gettin
On Feb 12, 2011, at 3:12 PM, Tom Lane wrote:
> "David E. Wheeler" 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 mand
"David E. Wheeler" 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 that
> they
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
> extensio
Dimitri Fontaine writes:
> Tom Lane 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 sq
Dimitri Fontaine writes:
> Tom Lane 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 is occurring to me here would
Tom Lane 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 sees this
>
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
Tom Lane writes:
> That would be rejected because you're not allowed to drop an individual
> member object of an extension. (And no, I don't want to have a kluge in
> dependency.c that makes that test work differently when
> creating_extension.)
Fair enough, all the more as soon as we have ALTER
Dimitri Fontaine writes:
> Tom Lane writes:
>> Actually, it occurs to me that the need for ALTER EXTENSION DROP could
>> be upon us sooner than we think. The cases where an extension upgrade
>> script would need that are
>> (1) you want to remove some deprecated piece of the extension's API;
>>
Tom Lane writes:
> Actually, it occurs to me that the need for ALTER EXTENSION DROP could
> be upon us sooner than we think. The cases where an extension upgrade
> script would need that are
> (1) you want to remove some deprecated piece of the extension's API;
> (2) you want to remove some no-lo
On Thu, Feb 10, 2011 at 10:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't
>>> add the object to multiple extensions; and it has a natural inverse,
>>> ALTER EXTENSION DROP.
Robert Haas writes:
> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't
>> add the object to multiple extensions; and it has a natural inverse,
>> ALTER EXTENSION DROP. I am not necessarily suggesting that we will ever
>> all
Dimitri Fontaine wrote:
> Tom Lane writes:
> > In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
> > back up to a must-have-for-9.1, since pg_upgrade would then leave you
> > with a non-upgraded extension.
> >
> > Now what?
>
> What would be the problem with pg_upgrade acting
On Feb 8, 2011, at 6:48 PM, Tom Lane wrote:
> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
> assuming that there can be only one owning extension for an object.
> Furthermore, it's not really intended for *removal* of an object from an
> extension (a concept that doesn't ev
Tom Lane writes:
> Hm, interesting idea, but I'm afraid that pg_describe_object doesn't
> produce exactly the syntax you need.
It's very close. I've produced the previous set like that and the only
problem I had were with operator class and family objects, and with
array types. In both case a v
Dimitri Fontaine writes:
> As far as upgrade script for contrib extensions are concerned, we will
> be able to produce them from SQL, right?
Hm, interesting idea, but I'm afraid that pg_describe_object doesn't
produce exactly the syntax you need.
I had personally been thinking of generating the
Tom Lane writes:
> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
> assuming that there can be only one owning extension for an object.
Yes, I worked from the SET SCHEMA variant and mentally mapped SET
EXTENSION there, if looked like the same idea applied to another
"propert
Robert Haas writes:
> On Tue, Feb 8, 2011 at 10:25 PM, Tom Lane wrote:
>> My point is that the current restriction to just one containing
>> extension seems to me to be an implementation restriction, rather than
>> something inherent in the concept of extensions. I have no intention of
>> trying
1 - 100 of 421 matches
Mail list logo
