On Wed, Feb 26, 2020 at 12:17:37AM -0800, Andres Freund wrote:
> Hi,
>
> On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote:
> > PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
> > automated testing (which broke since "FROM unpackaged" support was
> > removed, see 14514.1581638...
Hi,
On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote:
> PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
> automated testing (which broke since "FROM unpackaged" support was
> removed, see 14514.1581638...@sss.pgh.pa.us)
>
> We'd be ok with requiring SUPERUSER for doing that, si
On Thu, Feb 13, 2020 at 07:09:18PM -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> It seems to me that FROM UNPACKAGED shouldn't support trusted.
>
> > Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> > it given that "unpackaged" isn't magic in any way
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > On 2020-01-29 14:41:16 -0500, Tom Lane wrote:
> >> pgcrypto
>
> > FWIW, given the code quality, I'm doubtful about putting itq into the
> > trusted
> > section.
>
> I don't particularly have an opinion about that ---
Andres Freund writes:
> On 2020-02-13 18:57:10 -0500, Tom Lane wrote:
>> Maybe we could decide that the time for supporting easy updates from
>> pre-9.1 is past, and just remove all the unpackaged-to-XXX scripts?
>> Maybe even remove the "FROM version" option altogether.
> Yea, that strikes me as
Hi,
On 2020-02-13 18:57:10 -0500, Tom Lane wrote:
> Maybe we could decide that the time for supporting easy updates from
> pre-9.1 is past, and just remove all the unpackaged-to-XXX scripts?
> Maybe even remove the "FROM version" option altogether.
Yea, that strikes me as a reasonable thing to do
I wrote:
> Andres Freund writes:
>> It seems to me that FROM UNPACKAGED shouldn't support trusted.
> Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> it given that "unpackaged" isn't magic in any way so far as extension.c
> is concerned. Maybe we could decide that the
Andres Freund writes:
> On 2020-01-29 14:41:16 -0500, Tom Lane wrote:
>> pgcrypto
> FWIW, given the code quality, I'm doubtful about putting itq into the trusted
> section.
I don't particularly have an opinion about that --- is it really that
awful? If there is anything broken in it, wouldn't w
Hi,
On 2020-01-29 14:41:16 -0500, Tom Lane wrote:
> pgcrypto
FWIW, given the code quality, I'm doubtful about putting itq into the trusted
section.
Have you audited how safe the create/upgrade scripts are against being
used to elevate privileges?
Especially with FROM UNPACKAGED it seems like i
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Our previous
>> discussions about what privilege level is needed to look at
>> pg_stat_statements info were all made against a background assumption
>> that you needed some extra privilege to set up the view in the first
>> place.
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Julien Rouhaud writes:
> >>> Probably NO, if only because you'd need additional privileges
> >>> to use these anyway:
> >>> pg_stat_statements
>
> > But the additional privileges are global, so assuming the extension
> > has been properly setup
After looking more closely at these modules, I'm kind of inclined
*not* to put the trusted marker on intagg. That module is just
a backwards-compatibility wrapper around functionality that
exists in the core code nowadays. So I think what we ought to be
doing with it is deprecating and eventually
Dean Rasheed writes:
> On Wed, 29 Jan 2020 at 21:39, Tom Lane wrote:
>> The bigger picture here is that I don't want to get push-back that
>> we've broken somebody's security posture by marking too many extensions
>> trusted. So for anything where there's any question about security
>> implicati
On Wed, 29 Jan 2020 at 21:39, Tom Lane wrote:
>
> >>> pg_stat_statements
>
> Mmm, I'm not convinced --- the ability to see what statements are being
> executed in other sessions (even other databases) is something that
> paranoid installations might not be so happy about. Our previous
> discussio
Julien Rouhaud writes:
>>> Probably NO, if only because you'd need additional privileges
>>> to use these anyway:
>>> pg_stat_statements
> But the additional privileges are global, so assuming the extension
> has been properly setup, wouldn't it be sensible to ease the
> per-database installation
On Wed, Jan 29, 2020 at 9:46 PM Darafei "Komяpa" Praliaskouski
wrote:
>
> Hello,
>
>>
>> btree_gin
>> btree_gist
>
>
> I would even ask btree_gin and btree_gist to be moved to core.
Without going that far, I also agree that I relied on those extension
quite often, so +1 for marking them as truste
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes:
>> btree_gin
>> btree_gist
> I would even ask btree_gin and btree_gist to be moved to core.
That's not in scope here. Our past experience with trying to move
extensions into core is that it creates a pretty painful upgrade
experience f
Hello,
> btree_gin
> btree_gist
I would even ask btree_gin and btree_gist to be moved to core.
btree_gist is shipping opclasses for built in types to be used in gist
indexes. btree_* is confusing part in the name pretending there's some
magic happening linking btree and gist.
gist is the most
On 2020-Jan-29, Tom Lane wrote:
> Not sure what I think about these:
>
> bloom (are these useful in production?)
> btree_gin
> btree_gist
> pgrowlocks(seems safe, but are there security issues?)
> spi/autoinc (I doubt that these four are production grade)
> s
19 matches
Mail list logo
