Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Sep 27, 2016 at 4:43 AM, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> This is now being obsoleted by the later idea of allowing base installs
> >> from a chain of upgrade scripts.
On Tue, Sep 27, 2016 at 4:43 AM, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> This is now being obsoleted by the later idea of allowing base installs
>> from a chain of upgrade scripts. But if your upgrade scripts contain
>> ALTER TABLE commands, you will
Peter, all,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> This is now being obsoleted by the later idea of allowing base installs
> from a chain of upgrade scripts. But if your upgrade scripts contain
> ALTER TABLE commands, you will probably still want to write base install
> sc
Pushed with adjustments for the review points. Hopefully this will make
Stephen's life easier, along with others submitting contrib-module
updates. We should urge anyone who submits an old-style extension update
patch to consider whether they really want to bother with a new base
script.
At some
Andres Freund writes:
> On 2016-09-07 09:46:32 -0400, Tom Lane wrote:
>> + * If reject_indirect is true, ignore paths that go through installable
>> + * versions (presumably, caller will consider starting from such versions).
> Reading this I was initially confused, only after reading
> find_inst
On 2016-09-07 13:44:28 -0400, Tom Lane wrote:
> +
> +Installing Extensions using Update Scripts
> +
> +
> + An extension that has been around for awhile will probably exist in
Wanted to cry typo for 'awhile' here, but apparently that's actually a
word. The German in me is pleased.
Hi,
On 2016-09-07 09:46:32 -0400, Tom Lane wrote:
> At this point it's awfully tempting to make ALTER EXTENSION UPDATE grow
> a CASCADE option to allow automatic installation of new requirements
> of the new version, but I didn't do that here.
Sounds like a plan. After the refactoring that shoul
On 9/4/16 7:36 PM, Stephen Frost wrote:
> Perhaps if the versioned install script was actually a non-versioned
> install script in the source tree, and the Makefile simply installed it
> into the correct place, then we could eliminate that part. (All very
> hand-wavy, I've not looked at what it'd
I wrote:
> Still no SGML doc updates.
And here's a doc addition.
regards, tom lane
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index df88380..1c8c420 100644
*** a/doc/src/sgml/extend.sgml
--- b/doc/src/sgml/extend.sgml
*** SELECT * FROM pg
Andres Freund writes:
> On 2016-09-05 22:24:09 -0400, Tom Lane wrote:
>> Ordinarily I'd be willing to stick this on the queue for the next
>> commitfest, but it seems like we ought to try to get it pushed now
>> so that Stephen can make use of the feature for his superuser changes.
>> Thoughts?
>
On 2016-09-05 22:24:09 -0400, Tom Lane wrote:
> Ordinarily I'd be willing to stick this on the queue for the next
> commitfest, but it seems like we ought to try to get it pushed now
> so that Stephen can make use of the feature for his superuser changes.
> Thoughts?
Seems sensible to me. I can ha
Andres Freund writes:
> On September 4, 2016 6:33:30 PM PDT, Tom Lane wrote:
>> I think nearly all of the
>> infrastructure for this is already there in extension.c.
> Yes, it doesn't sound very hard...
I poked at this a bit, and indeed it's not that hard. Attached is a
proposed patch (code-co
On September 4, 2016 6:33:30 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2016-09-04 21:09:41 -0400, Tom Lane wrote:
>>> Hm, couldn't we do that automatically? At least in the case where
>only
>>> one base-version script is available?
>
>> You mean determining the baseversion? Hm, yes,
Andres Freund writes:
> On 2016-09-04 21:09:41 -0400, Tom Lane wrote:
>> Hm, couldn't we do that automatically? At least in the case where only
>> one base-version script is available?
> You mean determining the baseversion? Hm, yes, that might work. But I'm
> not sure how much we can rely on no
On 2016-09-04 21:09:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-04 11:55:06 -0400, Tom Lane wrote:
> >> It is becoming clear that the current extension update mechanism is kind
> >> of brute-force for this sort of change. I have no ideas offhand about a
> >> better way to do
Andres Freund writes:
> On 2016-09-04 11:55:06 -0400, Tom Lane wrote:
>> It is becoming clear that the current extension update mechanism is kind
>> of brute-force for this sort of change. I have no ideas offhand about a
>> better way to do it, but like Peter, I was dismayed by the amount of pure
On 2016-09-04 11:55:06 -0400, Tom Lane wrote:
> [ warning, thread hijack ahead ]
>
> Stephen Frost writes:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> I think this is a good change to pursue, and we'll likely want to do
> >> more similar changes in contrib. But I'm worr
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> [ warning, thread hijack ahead ]
quite.
> Stephen Frost writes:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> I think this is a good change to pursue, and we'll likely want to do
> >> more similar changes in contrib. But I'm
[ warning, thread hijack ahead ]
Stephen Frost writes:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> I think this is a good change to pursue, and we'll likely want to do
>> more similar changes in contrib. But I'm worried that what is logically
>> a 10-line change will end up
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 8/23/16 5:22 PM, Stephen Frost wrote:
> > Now that we track initial privileges on extension objects and changes to
> > those permissions, we can drop the superuser() checks from the various
> > functions which are part of the pgstatt
On 8/23/16 5:22 PM, Stephen Frost wrote:
> Now that we track initial privileges on extension objects and changes to
> those permissions, we can drop the superuser() checks from the various
> functions which are part of the pgstattuple extension.
>
> Since a pg_upgrade will preserve the version of
21 matches
Mail list logo
