Re: [HACKERS] Change in "policy" on dump ordering?

[Jordan Gigov]

But why should a superuser need the ACL to be applied before being allowed
access? If you make the permission-checking function check if the user is a
superuser before looking for per-user grants, wouldn't that solve the issue?

On 26 July 2017 at 16:30, Tom Lane  wrote:

> Robert Haas  writes:
> > On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane  wrote:
> >> Instead, I've prepared the attached draft patch, which addresses the
> >> problem by teaching pg_backup_archiver.c to process TOC entries in
> >> three separate passes, "main" then ACLs then matview refreshes.
>
> > What worries me a bit is the possibility that something might depend
> > on a matview having already been refreshed.  I cannot immediately
> > think of a case whether such a thing happens that you won't dismiss as
> > wrong-headed, but how sure are we that none such will arise?
>
> Um, there are already precisely zero guarantees about that.  pg_dump
> has always been free to order these actions in any way that satisfies
> the dependencies it knows about.
>
> It's certainly possible to break it by introducing hidden dependencies
> within CHECK conditions.  But that's always been true, with or without
> materialized views, and we've always dismissed complaints about it with
> "sorry, we won't support that".  (I don't think the trigger case is
> such a problem, because we restore data before creating any triggers.)
>
> Meanwhile, we have problems that bite people who aren't doing anything
> stranger than having a matview owned by a non-superuser.  How do you
> propose to fix that without reordering pg_dump's actions?
>
> Lastly, the proposed patch has the advantage that it acts at the restore
> stage, not when a dump is being prepared.  Since it isn't affecting what
> goes into dump archives, it doesn't tie our hands if we think of some
> better idea later.
>
> regards, tom lane
>

[HACKERS] jsonb problematic operators

[Jordan Gigov]

There is this problem with the jsonb operators "? text" "?| text[]"
and "?& text[]" that the question mark is typically used for prepared
statement parameters in the most used abstraction APIs in Java and
PHP.

This really needs an alternative. Something like "HAS text", "HAS
ANY(text[])" and "HAS ALL(text[])" same as regular array usage. It
probably should be another word that has less chance of becoming a
conflict with another operator in future SQL specifications, but
that's for you to decide.

It's not a good idea to expect everyone else to make for workarounds
for problems you choose to create.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers