Re: public schema default ACL

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: public schema default ACL
Дата
Msg-id 20201018125147.GA2280743@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: public schema default ACL  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Wed, Aug 05, 2020 at 10:00:02PM -0700, Noah Misch wrote:
> On Mon, Aug 03, 2020 at 09:46:23AM -0400, Robert Haas wrote:
> > On Mon, Aug 3, 2020 at 2:30 AM Noah Misch <noah@leadboat.com> wrote:
> > > Between (b)(2)(X) and (b)(3)(X), what are folks' preferences?  Does anyone
> > > strongly favor some other option (including the option of changing nothing)
> > > over both of those two?
> > 
> > I don't think we have any options here that are secure but do not
> > break backward compatibility.
> 
> I agree, but compatibility breaks vary in pain caused.  I want to offer a
> simple exit to a backward-compatible configuration, and I want a $NEW_DEFAULT
> pleasing enough that a decent fraction of deployments keep $NEW_DEFAULT (forgo
> the exit).  The move to default standard_conforming_strings=on is an example
> to follow (editing postgresql.conf was the simple exit).
> 
> > I don't know how to choose between (1), (2), and (3).
> 
> One way is to envision deployments you know and think about a couple of
> questions in the context of those deployments.  If $EACH_OPTION happened,
> would this deployment keep $NEW_DEFAULT, override $NEW_DEFAULT to some other
> secure configuration, or exit to $v13_DEFAULT?  Where the answer is "exit",
> would those deployments rate the exit recipe easy, medium, or difficult?

It sounds like you might prefer to wait for better ideas and not change
$SUBJECT for now.  Is that right?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Add extra statistics to explain for Nested Loop
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_restore error message during ENOSPC with largeobj