Michael Paquier writes:
> I also don't quite understand the argument of application relying on
> this behavior. If they do, that's wrong anyway, so the risk of
> operation disruptions for shared environments would matter more in my
> opinion.
I'm not totally sure about that. If you suppose that
On Mon, Apr 16, 2018 at 08:12:45PM +0300, Alexander Lakhin wrote:
> The worst scenario (with the current system views) I could think of is:
> user=> CREATE VIEW pgg AS SELECT * FROM pg_group;
> BEGIN TRANSACTION; SELECT * FROM pgg FOR UPDATE; SELECT pg_sleep(60);
> ROLLBACK;
> and the parallel oper
13.04.2018 18:55, Tom Lane wrote:
Although this is arguably a security bug, I'm not sure we should
back-patch it. The consequences seem relatively minor, and the
behavioral change carries a significant risk of breaking applications
that worked as-intended up to now. Thoughts?
The worst scenari
Alexander Lakhin writes:
> Can you please explain, is this a bug or intended behaviour?
I'd say it's a bug. The permissions restriction should apply even with
the intermediate view.
After some rooting around, it seems like this can be blamed on wrong
order-of-operations in ApplyRetrieveRule().
Hello hackers,
Can you please explain, is this a bug or intended behaviour?
Running as non-privileged user:
postgres=> SELECT datid, datname FROM pg_stat_database FOR UPDATE;
ERROR: permission denied for view pg_stat_database (SQLState: 42501)
But:
postgres=> CREATE VIEW pgsd AS SELECT * FROM
