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
Greetings,
Attached is an rebased and updated patch to remove the explicit
superuser() checks from the contrib extension pgstattuple, in favor of
using the GRANT system to control access, and give the admin flexibility
to GRANT access to this function without having to write wrapper
functions, sim
22 matches
Mail list logo