On 2024-Feb-25, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Feb-22, Tom Lane wrote:
> >> While I've not done anything about that here, I wonder if we shouldn't
> >> just write "privilege on the target table" without any special markup.
>
> > That would work for me.
>
> OK. Will you
Alvaro Herrera writes:
> On 2024-Feb-22, Tom Lane wrote:
>> While I've not done anything about that here, I wonder if we shouldn't
>> just write "privilege on the target table" without any special markup.
> That would work for me.
OK. Will you do the honors, or shall I?
On 2024-Feb-22, Tom Lane wrote:
> Alvaro Herrera writes:
> > I propose the attached. (Extra context so that the full paragraph can
> > be read from the comfort of your email program.)
>
> This reads awkwardly to me. I think it'd be better to construct it
> so that DO NOTHING's requirement is
Alvaro Herrera writes:
> After having pushed that, I wonder if we should document this. It seems
> quite the minor thing, but I'm sure somebody will complain if we don't.
Yup, no doubt.
> I propose the attached. (Extra context so that the full paragraph can
> be read from the comfort of your
On 2024-Feb-20, Tom Lane wrote:
> > So, this means we can fix this by simply requiring ACL_SELECT privileges
> > on a DO NOTHING action. We don't need to request specific privileges on
> > any particular column (perminfo->selectedCols continues to be the empty
> > set) -- which means that any
Alvaro Herrera writes:
> The real problem is that a MERGE ... DO NOTHING action reports that no
> permissions need to be checked on the target relation, which is not a
> problem when there are other actions in the MERGE command since they add
> privs to check. When DO NOTHING is the only action,
On 2024-Feb-18, Alvaro Herrera wrote:
> On 2024-Feb-18, Tom Lane wrote:
>
> > So I'd blame this on faulty handling of the zero-partitions case in
> > the RTEPermissionInfo refactoring. (I didn't bisect to prove that
> > a61b1f748 is exactly where it broke, but I do see that the query
> >
On Mon, Feb 19, 2024 at 4:44 AM Alvaro Herrera wrote:
> On 2024-Feb-18, Tom Lane wrote:
>
> > So I'd blame this on faulty handling of the zero-partitions case in
> > the RTEPermissionInfo refactoring. (I didn't bisect to prove that
> > a61b1f748 is exactly where it broke, but I do see that the
On 2024-Feb-18, Tom Lane wrote:
> So I'd blame this on faulty handling of the zero-partitions case in
> the RTEPermissionInfo refactoring. (I didn't bisect to prove that
> a61b1f748 is exactly where it broke, but I do see that the query
> successfully does nothing in v15.)
You're right, this is
Alena Rybakina writes:
> After starting the server (initdb + pg_ctl start) I ran a regress test
> create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after
> that,
> I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in
> the psql, and it failed in the core-dump
Hi, hackers!
After starting the server (initdb + pg_ctl start) I ran a regress test
create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after
that,
I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in
the psql, and it failed in the core-dump due to the worked
11 matches
Mail list logo
