Hi,
On Mon, Jan 31, 2022 at 09:14:21AM -0600, David Christensen wrote:
>
> Sounds good; when I get time to look at this again I will resubmit (if
> people think the base functionality is worth it, which is still a topic of
> discussion).
Yes, please do! Sorry I should have mentioned it, if a pa
On Sun, Jan 30, 2022 at 9:47 PM Julien Rouhaud wrote:
> Hi,
>
> On Tue, Jan 25, 2022 at 10:26:53PM +0800, Julien Rouhaud wrote:
> >
> > It's been almost 4 months since your last email, and almost 2 weeks
> since the
> > notice that this patch doesn't apply anymore. Without update in the next
> >
Hi,
On Tue, Jan 25, 2022 at 10:26:53PM +0800, Julien Rouhaud wrote:
>
> It's been almost 4 months since your last email, and almost 2 weeks since the
> notice that this patch doesn't apply anymore. Without update in the next
> couple of days this patch will be closed as Returned with Feedback pe
Hi,
On Wed, Jan 12, 2022 at 04:57:27PM +0800, Julien Rouhaud wrote:
>
> The cfbot reports that this patch doesn't apply anymore:
> http://cfbot.cputube.org/patch_36_3195.log
>
> > patching file src/backend/utils/adt/ri_triggers.c
> > Hunk #1 succeeded at 93 (offset 3 lines).
> > Hunk #2 FAILED a
Hi,
On Wed, Sep 29, 2021 at 03:55:22PM -0500, David Christensen wrote:
>
> I can see the argument for this in terms of being cautious/explicit about
> what gets removed, however
> the utility in this particular form was related to being able to *avoid*
> having to manually figure out
> the rela
as well.
> Returning to the original thought of a DML statement option to temporarily
> override the referential_action, I wonder why only temporarily-set-CASCADE
> was considered. It seems to me like there might also be use-cases for
> temporarily selecting the SET NULL or SET DEFAU
[ a couple of random thoughts after quickly scanning this thread ... ]
David Christensen writes:
> I assume this would look something like:
> ALTER TABLE foo ALTER CONSTRAINT my_fkey ON UPDATE CASCADE ON DELETE RESTRICT
> with omitted referential_action implying preserving the existing one.
I se
David G. Johnston writes:
> Having the defined FK behaviors be more readily changeable, while not
> mitigating this need, is IMO a more important feature to implement. If
> there is a reason that cannot be implemented (besides no one has bothered
> to take the time) then I would consider that r
the foreign key - the behavior should
> be identical to on cascade delete.
>
I think Peter is referring to the DELETE RESTRICT proposed mirror behavior
in this specific case, not DELETE CASCADE specifically.
> I require convincing that there is a use case that requires laxer
> permis
On Wednesday, June 9, 2021, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> It might work, I'm just saying it needs to be thought about carefully. If
> you have functionality like, delete this if there is no matching record
> over there, you need to have the permission to check th
On 08.06.21 21:25, David Christensen wrote:
I sense more complicated concurrency and permission issues, however.
Assuming this happens in the same transaction, wouldn't this just work?
Or are you thinking there needs to be some sort of predicate lock to
prevent a concurrent add of the ref
On 08.06.21 21:29, David Christensen wrote:
> So basically where we are dispatching to the CASCADE guts, first
check session user’s DELETE permission and throw the normal
permissions error if they can’t delete?
Actually, you also need appropriate SELECT permissions that correspo
>
> > So basically where we are dispatching to the CASCADE guts, first check
> session user’s DELETE permission and throw the normal permissions error if
> they can’t delete?
>
> Actually, you also need appropriate SELECT permissions that correspond
> to the WHERE clause of the DELETE statement.
>
gt;> On 03.06.21 22:49, David Christensen wrote:
> >>> Presented for discussion is a POC for a DELETE CASCADE functionality,
> which will allow you one-shot usage of treating existing NO ACTION and
> RESTRICT FK constraints as if they were originally defined as CASCADE
> con
On 05.06.21 14:25, David Christensen wrote:
On Jun 5, 2021, at 2:29 AM, Peter Eisentraut
wrote:
On 04.06.21 22:24, David Christensen wrote:
So what are the necessary and sufficient conditions to check at this point?
The constraint already exists, so what permissions would we need to chec
On 05.06.21 14:21, David Christensen wrote:
On Jun 5, 2021, at 2:30 AM, Peter Eisentraut
wrote:
On 03.06.21 22:49, David Christensen wrote:
Presented for discussion is a POC for a DELETE CASCADE functionality, which will allow
you one-shot usage of treating existing NO ACTION and
> On Jun 5, 2021, at 2:29 AM, Peter Eisentraut
> wrote:
>
> On 04.06.21 22:24, David Christensen wrote:
>> So what are the necessary and sufficient conditions to check at this point?
>> The constraint already exists, so what permissions would we need to check
>> against which table(s) in o
On Sat, 5 Jun 2021 at 03:30, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.06.21 22:49, David Christensen wrote:
> > Presented for discussion is a POC for a DELETE CASCADE functionality,
> > which will allow you one-shot usage of treating existing NO AC
> On Jun 5, 2021, at 2:30 AM, Peter Eisentraut
> wrote:
>
> On 03.06.21 22:49, David Christensen wrote:
>> Presented for discussion is a POC for a DELETE CASCADE functionality, which
>> will allow you one-shot usage of treating existing NO ACTION and RESTRICT FK
&
On 03.06.21 22:49, David Christensen wrote:
Presented for discussion is a POC for a DELETE CASCADE functionality,
which will allow you one-shot usage of treating existing NO ACTION and
RESTRICT FK constraints as if they were originally defined as CASCADE
constraints. I can't tell you how
On 04.06.21 22:24, David Christensen wrote:
So what are the necessary and sufficient conditions to check at this
point? The constraint already exists, so what permissions would we need
to check against which table(s) in order to grant this action?
I think you would need DELETE privilege on al
t,
> PRIMARY KEY (pid, cid),
> child_data text
> );
>
> It's easy to imagine needing to write:
>
> DELETE FROM child WHERE ...
> DELETE FROM parent WHERE ...
>
> ... where the WHERE clauses both work out to the same pid values. It would
> be nice to
ould require the same permissions as actually creating
>> > an ON DELETE CASCADE FK on the cascaded-to tables. i.e., Table Owner
>> > role membership (the requirement for FK permissions can be assumed by
>> > the presence of the existing FK constraint and being the ta
On Fri, Jun 4, 2021 at 2:53 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.06.21 23:47, David G. Johnston wrote:
> > This behavior should require the same permissions as actually creating
> > an ON DELETE CASCADE FK on the cascaded-to tables. i.e.,
On 03.06.21 23:47, David G. Johnston wrote:
This behavior should require the same permissions as actually creating
an ON DELETE CASCADE FK on the cascaded-to tables. i.e., Table Owner
role membership (the requirement for FK permissions can be assumed by
the presence of the existing FK
On Thu, Jun 3, 2021 at 3:29 PM Isaac Morland
wrote:
> Surely you mean if we don't have DELETE permission on the referencing
> table? I don't see why we need to be a member of the table owner role.
>
I would reverse the question - why does this feature need to allow the more
broad DELETE permissi
this, so keep 'em
>> coming... :-))
>>
>
> Enclosed is a basic test script and the corresponding output run through
> `psql -e` (will adapt into part of the regression test, but wanted to get
> this out there). TL;DR; DELETE CASCADE behaves exactly as if said
> con
cing
table. So based on what you say, it sounds like you've already covered this
issue.
Sidebar: isn't this inconsistent with trigger behaviour in general? When I
>> say "ON DELETE CASCADE" what I mean and what I get are the same: whenever
>> the referenced row
dapt into part of the regression test, but wanted to get
this out there). TL;DR; DELETE CASCADE behaves exactly as if said
constraint were defined as a ON DELETE CASCADE FK constraint wrt DELETE
permission behavior. I do agree in this case, that it makes sense to throw
an error if we're trying t
On Thu, Jun 3, 2021 at 4:15 PM Isaac Morland
wrote:
> On Thu, 3 Jun 2021 at 16:49, David Christensen <
> david.christen...@crunchydata.com> wrote:
>
>> Hi -hackers,
>>
>> Presented for discussion is a POC for a DELETE CASCADE functionality,
>> which wi
On Thu, Jun 3, 2021 at 4:48 PM David G. Johnston
wrote:
> On Thu, Jun 3, 2021 at 1:49 PM David Christensen <
> david.christen...@crunchydata.com> wrote:
>
>> Presented for discussion is a POC for a DELETE CASCADE functionality,
>> which will allow you one-shot us
On Thu, Jun 3, 2021 at 1:49 PM David Christensen <
david.christen...@crunchydata.com> wrote:
> Presented for discussion is a POC for a DELETE CASCADE functionality,
> which will allow you one-shot usage of treating existing NO ACTION and
> RESTRICT FK constraints as if they
On Thu, 3 Jun 2021 at 16:49, David Christensen <
david.christen...@crunchydata.com> wrote:
> Hi -hackers,
>
> Presented for discussion is a POC for a DELETE CASCADE functionality,
> which will allow you one-shot usage of treating existing NO ACTION and
> RESTRICT FK constr
Hi -hackers,
Presented for discussion is a POC for a DELETE CASCADE functionality,
which will allow you one-shot usage of treating existing NO ACTION and
RESTRICT FK constraints as if they were originally defined as CASCADE
constraints. I can't tell you how many times this functionality
34 matches
Mail list logo
