On 28.09.22 00:39, Kaiting Chen wrote:
What other semantics and edge cases regarding this proposal should I
consider?
I'm not as pessimistic as others that it couldn't be made to work. But
it's the job of this proposal to figure this out. Implementing it is
probably not that hard in the end
> For one example of where the semantics get fuzzy, it's not
> very clear how the extra-baggage columns ought to participate in
> CASCADE updates. Currently, if we have
>CREATE TABLE foo (a integer PRIMARY KEY, b integer);
> then an update that changes only foo.b doesn't need to update
> refer
> So the broader point I'm trying to make is that, as I understand it,
> indexes backing foreign key constraints is an implementation detail.
> The SQL standard details the behavior of foreign key constraints
> regardless of implementation details like a backing index. That means
> that the behavio
>>> Another example is that I think the idea is only well-defined when
>>> the subset column(s) are a primary key, or at least all marked NOT NULL.
>>> Otherwise they're not as unique as you're claiming. But then the FK
>>> constraint really has to be dependent on a PK constraint not just an
>>> i
Kaiting Chen writes:
>> Another example is that I think the idea is only well-defined when
>> the subset column(s) are a primary key, or at least all marked NOT NULL.
>> Otherwise they're not as unique as you're claiming. But then the FK
>> constraint really has to be dependent on a PK constraint
> Could we create this additional unique constraint implicitly, when using
> FOREIGN KEY ... REFERENCES on a superset of unique columns? This would
> make it easier to use, but still give proper information_schema output.
Currently, a foreign key declared where the referenced columns have only a
u
> As I was reading through the email chain I had this thought: could you
> get the same benefit (or 90% of it anyway) by instead allowing the
> creation of a uniqueness constraint that contains more columns than
> the index backing it? So long as the index backing it still guaranteed
> the uniquene
> For one example of where the semantics get fuzzy, it's not
> very clear how the extra-baggage columns ought to participate in
> CASCADE updates. Currently, if we have
>CREATE TABLE foo (a integer PRIMARY KEY, b integer);
> then an update that changes only foo.b doesn't need to update
> refer
On Tue, 27 Sept 2022 at 06:08, James Coleman wrote:
>
> On Mon, Sep 26, 2022 at 9:59 AM Wolfgang Walther
> wrote:
> > So no need for me to distract this thread from $subject anymore. I think
> > the idea of allowing to create unique constraints on a superset of the
> > columns of an already exist
On Mon, Sep 26, 2022 at 10:04 AM Wolfgang Walther
wrote:
>
> James Coleman:
> > As I was reading through the email chain I had this thought: could you
> > get the same benefit (or 90% of it anyway) by instead allowing the
> > creation of a uniqueness constraint that contains more columns than
> >
On Mon, Sep 26, 2022 at 9:59 AM Wolfgang Walther
wrote:
>
> James Coleman:
> > So the broader point I'm trying to make is that, as I understand it,
> > indexes backing foreign key constraints is an implementation detail.
> > The SQL standard details the behavior of foreign key constraints
> > rega
James Coleman:
As I was reading through the email chain I had this thought: could you
get the same benefit (or 90% of it anyway) by instead allowing the
creation of a uniqueness constraint that contains more columns than
the index backing it? So long as the index backing it still guaranteed
the u
James Coleman:
So the broader point I'm trying to make is that, as I understand it,
indexes backing foreign key constraints is an implementation detail.
The SQL standard details the behavior of foreign key constraints
regardless of implementation details like a backing index. That means
that the
On Mon, Sep 26, 2022 at 2:28 AM Wolfgang Walther
wrote:
>
> James Coleman:
> > If we have a declared constraint on x,y where x is unique based on an
> > index including on x I do not think we should have that fk constraint
> > work differently than a constraint on x,y where there is a unique
> > i
James Coleman:
If we have a declared constraint on x,y where x is unique based on an
index including on x I do not think we should have that fk constraint
work differently than a constraint on x,y where there is a unique
index on x,y. That would seem to be incredibly confusing behavior
(even if i
Hello Kaiting,
The use case you're looking to handle seems interesting to me.
On Wed, Jul 27, 2022 at 3:11 PM Tom Lane wrote:
>
> Kaiting Chen writes:
> > I'd like to propose a change to PostgreSQL to allow the creation of a
> > foreign
> > key constraint referencing a superset of uniquely con
On Sun, Sep 25, 2022 at 4:49 AM Wolfgang Walther
wrote:
>
> James Coleman:
> > If I'm following properly this sounds like an overengineered EAV
> > schema, and neither of those things inspires me to think "this is a
> > use case I want to support".
> >
> > That being said, I know that sometimes ex
James Coleman:
If I'm following properly this sounds like an overengineered EAV
schema, and neither of those things inspires me to think "this is a
use case I want to support".
That being said, I know that sometimes examples that have been
abstracted enough to share aren't always the best, so pe
On Fri, Sep 2, 2022 at 5:42 AM Wolfgang Walther wrote:
>
> Kaiting Chen:
> > I'd like to propose a change to PostgreSQL to allow the creation of a
> > foreign
> > key constraint referencing a superset of uniquely constrained columns.
>
> +1
>
> Tom Lane:
> > TBH, I think this is a fundamentally b
Kaiting Chen:
I'd like to propose a change to PostgreSQL to allow the creation of a foreign
key constraint referencing a superset of uniquely constrained columns.
+1
Tom Lane:
TBH, I think this is a fundamentally bad idea and should be rejected
outright. It fuzzes the semantics of the FK rel
Kaiting Chen writes:
> I'd like to propose a change to PostgreSQL to allow the creation of a foreign
> key constraint referencing a superset of uniquely constrained columns.
TBH, I think this is a fundamentally bad idea and should be rejected
outright. It fuzzes the semantics of the FK relations
On Fri, Jun 10, 2022 at 12:14 AM Peter Eisentraut
wrote:
>
> On 10.06.22 05:47, David Rowley wrote:
> >> I think this should be referring to constraint name, not an index name.
> > Can you explain why you think that?
>
> If you wanted to specify this feature in the SQL standard (I'm not
> proposin
On Fri, 10 Jun 2022 at 16:14, Peter Eisentraut
wrote:
>
> On 10.06.22 05:47, David Rowley wrote:
> >> I think this should be referring to constraint name, not an index name.
> > Can you explain why you think that?
>
> If you wanted to specify this feature in the SQL standard (I'm not
> proposing t
On 10.06.22 05:47, David Rowley wrote:
I think this should be referring to constraint name, not an index name.
Can you explain why you think that?
If you wanted to specify this feature in the SQL standard (I'm not
proposing that, but it seems plausible), then you need to deal in terms
of con
On Fri, 10 Jun 2022 at 15:08, Peter Eisentraut
wrote:
>
> On 07.06.22 20:59, Kaiting Chen wrote:
> > 2. The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ]
> > clause
> > optionally following the referenced column list.
> >
> > The index specified by this clause is used t
On 07.06.22 20:59, Kaiting Chen wrote:
2. The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ] clause
optionally following the referenced column list.
The index specified by this clause is used to support the foreign key
constraint, and it must be a non-deferrable uni
Hi everyone:
I'd like to propose a change to PostgreSQL to allow the creation of a foreign
key constraint referencing a superset of uniquely constrained columns.
As it currently stands:
CREATE TABLE foo (a integer PRIMARY KEY, b integer);
CREATE TABLE bar (x integer, y integer,
FOREIGN K
27 matches
Mail list logo
