On Wed, 21 Aug 2024 at 10:08, jian he wrote:
>
> the following setup is extract from src/test/regress/sql/updatable_views.sql
> you can search keywords: "-- ordinary view on top of security invoker
> view permissions"
>
> CREATE TABLE base_tbl(a int, b text, c float);
> INSERT INTO base_tbl VALUES
On Thu, 13 Oct 2022 at 18:17, Tom Lane wrote:
>
> I'm inclined to think that we should push the responsibility for choosing
> its rscale into power_var_int(), because internally that already does
> estimate the result weight, so with a little code re-ordering we won't
> need duplicative estimates.
On Mon, 12 Jul 2021 at 02:39, David G. Johnston
wrote:
>
> One, the select generate_series(1,3) function call causes multiple rows to be
> generated where there would usually be only one.
Yes.
> Two, composition results in an inside-to-outside execution order: the SRF is
> evaluated first, the
On Sun, 24 Mar 2019 at 08:01, Steve Baldwin wrote:
>
> Thanks Tom,
>
> I've tried this on 11.2 (OS X 10.14.3, installed locally) and 10.6 (AWS RDS)
> instances with identical results. The values you show are identical to those
> returned by Oracle so that's great but why am I seeing different r
On Mon, 1 Oct 2018 at 21:45, Carl Sverre wrote:
> Dean,
> Thank you for the pointer towards visibility/volatility. I think that
> completely explains the effect that I am seeing in my repro. I experimented
> with using a VOLATILE function for the SELECT RLS using statement and while
> it comp
The real issue here is to do with the visibility of the data inserted
by the trigger function from within the same command. In general, data
inserted by a command is not visible from within that same command.
The easiest way to see what's going on is with a simple example.
Consider the following (
On 28 August 2018 at 01:49, Alvaro Herrera wrote:
> On 2018-Aug-27, Ken Tanzer wrote:
>>- In the scheme of things, is it a lot of work or not so much?
>
> Probably not much.
>
Yeah, it doesn't seem like it would be particularly difficult, but it
would probably still be a reasonable amount of
On 24 July 2018 at 15:25, Simon Brent wrote:
> I've been using postgres for a while now, and have just started looking in
> to row level security. I have found something that I think is a bit strange,
> and wanted to know if anyone knows how/why it is the case.
>
> I have a table with multiple pol
