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
Tom Lane writes:
> [ 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 prese
[ 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
On Wed, Jun 9, 2021 at 8:48 AM David G. Johnston
wrote:
> 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 matchin
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.
>
On Mon, Jun 7, 2021 at 2:54 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 05.06.21 14:21, David Christensen wrote:
> >
> >> On Jun 5, 2021, at 2:30 AM, Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
> >>
> >> On 03.06.21 22:49, David Christensen wrote:
> >>>
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 RESTRICT
> 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 ACTION and
> > RESTRICT
> 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
>> constraints as if they we
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 many
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
On Fri, Jun 4, 2021 at 3:40 PM Isaac Morland
wrote:
> I apologize if I am deeply confused, but say I have this:
>
> CREATE TABLE parent (
> pid int primary key,
> parent_data text
> );
>
> CREATE TABLE child (
> pid int REFERENCES parent,
> cid int,
> PRIMARY KEY (pid, cid),
>
On Fri, 4 Jun 2021 at 16:24, David Christensen <
david.christen...@crunchydata.com> wrote:
> 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 actu
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., Table Owner
> > role me
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 constrai
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
On Thu, 3 Jun 2021 at 18:25, David Christensen <
david.christen...@crunchydata.com> wrote:
> What happens if I don't have delete permission on the referencing table?
>>> When a foreign key reference delete cascades, I can cause records to
>>> disappear from a referencing table even if I don't have
On Thu, 3 Jun 2021 at 18:08, David Christensen <
david.christen...@crunchydata.com> wrote:
> On Thu, Jun 3, 2021 at 4:15 PM Isaac Morland
> wrote:
>
>>
>> What happens if I don't have delete permission on the referencing table?
>> When a foreign key reference delete cascades, I can cause records
>
> What happens if I don't have delete permission on the referencing table?
>> When a foreign key reference delete cascades, I can cause records to
>> disappear from a referencing table even if I don't have delete permission
>> on that table. This feels like it's just supposed to be a convenience
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 will allow you one-shot usage of treating exist
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 usage of treating existing NO ACTION
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 were originally defined
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 constraints as if they were ori
33 matches
Mail list logo
