On 02.12.21 01:17, Paul Martinez wrote:
Regarding that specific example, in a production scenario, yes, the
DELETE command should reference both columns. And if used for
documentation both columns should be referenced for clarity/correctness.
Ok, thanks. I have updated your example accordingly
On Wed, Nov 24, 2021 at 10:59 AM Peter Eisentraut
wrote:
>
> I was looking through this example to see if it could be adapted for the
> documentation.
>
> The way the users table is defined, it appears that "id" is actually
> unique and the primary key ought to be just (id). The DELETE command
>
On Wed, 1 Dec 2021 at 11:33, Peter Eisentraut
wrote:
>
> On 23.11.21 05:44, Paul Martinez wrote:
> > Updated patch attached. Thanks for taking a look so quickly!
>
> This patch looks pretty much okay to me. As I wrote in another message
> in this thread, I'm having some doubts about the proper us
On 23.11.21 05:44, Paul Martinez wrote:
Updated patch attached. Thanks for taking a look so quickly!
This patch looks pretty much okay to me. As I wrote in another message
in this thread, I'm having some doubts about the proper use case. So
I'm going to push this commit fest entry to the ne
On 05.01.21 22:40, Paul Martinez wrote:
CREATE TABLE tenants (id serial PRIMARY KEY);
CREATE TABLE users (
tenant_id int REFERENCES tenants ON DELETE CASCADE,
id serial,
PRIMARY KEY (tenant_id, id),
);
CREATE TABLE posts (
tenant_id int REFERENCES tenants ON DELETE CASCADE,
id
On Mon, Nov 22, 2021 at 10:21 PM Zhihong Yu wrote:
>
> Hi,
> + If a foreign key with a SET NULL or SET
> + DEFAULT delete action, which columns should be updated.
>
> which columns should be updated -> the columns that should be updated
Done.
> + if (fk_del_set_cols)
> + {
> +
On Mon, Nov 22, 2021 at 8:04 PM Paul Martinez wrote:
> On Thu, Nov 11, 2021 at 4:34 AM Peter Eisentraut
> wrote:
> >
> > I have reviewed your patch
> > referential-actions-on-delete-only-set-cols-v3.patch. Attached are two
> > patches that go on top of yours that contain my recommended changes.
On Thu, Nov 11, 2021 at 4:34 AM Peter Eisentraut
wrote:
>
> I have reviewed your patch
> referential-actions-on-delete-only-set-cols-v3.patch. Attached are two
> patches that go on top of yours that contain my recommended changes.
>
> Basically, this all looks pretty good to me. My changes are m
I have reviewed your patch
referential-actions-on-delete-only-set-cols-v3.patch. Attached are two
patches that go on top of yours that contain my recommended changes.
Basically, this all looks pretty good to me. My changes are mostly
stylistic.
Some notes of substance:
- The omission of t
On Thu, Sep 2, 2021 at 1:55 PM Zhihong Yu wrote:
>
> Hi,
> + case RI_TRIGTYPE_DELETE:
> + queryno = is_set_null
> + ? RI_PLAN_ONDELETE_SETNULL_DOUPDATE
> + : RI_PLAN_ONDELETE_SETDEFAULT_DOUPDATE;
>
> Should the new symbols be renamed ?
>
> RI_PLAN_ONDELE
On Thu, Sep 2, 2021 at 12:11 PM Paul Martinez wrote:
> On Wed, Sep 1, 2021 at 4:11 AM Daniel Gustafsson wrote:
>
> > This patch no longer applies, can you please submit a rebased version?
> It
> > currently fails on catversion.h, to keep that from happening repeatedly
> you can
> > IMO skip that
On Wed, Sep 1, 2021 at 4:11 AM Daniel Gustafsson wrote:
> This patch no longer applies, can you please submit a rebased version? It
> currently fails on catversion.h, to keep that from happening repeatedly you
> can
> IMO skip that from the patch submission.
Ah, understood. Will do that in the
> On 4 Aug 2021, at 23:49, Paul Martinez wrote:
> I've rebased my original patch and it should work now.
This patch no longer applies, can you please submit a rebased version? It
currently fails on catversion.h, to keep that from happening repeatedly you can
IMO skip that from the patch submis
On Wed, Jul 14, 2021 at 6:51 AM Peter Eisentraut
wrote:
> I think this is an interesting feature with a legitimate use case.
Great! I'm glad to hear that.
> Consider what should happen when you update users.id. Per SQL standard,
> for MATCH SIMPLE an ON UPDATE SET NULL should only set to null t
On Wed, Jul 14, 2021 at 6:51 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 05.01.21 22:40, Paul Martinez wrote:
> > I've created a patch to better support referential integrity constraints
> when
> > using composite primary and foreign keys. This patch allows creating a
>
On 05.01.21 22:40, Paul Martinez wrote:
I've created a patch to better support referential integrity constraints when
using composite primary and foreign keys. This patch allows creating a foreign
key using the syntax:
FOREIGN KEY (tenant_id, fk_id) REFERENCES fktable ON DELETE SET NULL (fk
On 3/18/21 9:52 AM, David Steele wrote:
On 1/5/21 4:40 PM, Paul Martinez wrote:
I've created a patch to better support referential integrity
constraints when
using composite primary and foreign keys. This patch allows creating a
foreign
key using the syntax:
I previously proposed this fe
On 1/5/21 4:40 PM, Paul Martinez wrote:
I've created a patch to better support referential integrity constraints when
using composite primary and foreign keys. This patch allows creating a foreign
key using the syntax:
I previously proposed this feature about a year ago [1], but I don't fee
Hey, hackers!
I've created a patch to better support referential integrity constraints when
using composite primary and foreign keys. This patch allows creating a foreign
key using the syntax:
FOREIGN KEY (tenant_id, fk_id) REFERENCES fktable ON DELETE SET NULL (fk_id)
which means that only th
19 matches
Mail list logo
