From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Matthew Woodcraft <matthew(at)woodcraft(dot)me(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UPSERT wiki page, and SQL MERGE syntax |
Date: | 2014-10-12 12:40:35 |
Message-ID: | 543A76C3.3000609@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/12/14, 2:36 PM, Matthew Woodcraft wrote:
> On 2014-10-10 19:44, Kevin Grittner wrote:
>> To restate: to do so is conflating the logical definition of the
>> database with a particular implementation detail. As just one
>> reason that is a bad idea: we can look up unique indexes on the
>> specified columns, but if we implement a other storage techniques
>> where there is no such thing as a unique index on the columns, yet
>> manage to duplicate the semantics (yes, stranger things have
>> happened), people can't migrate to the new structure without
>> rewriting their queries
>
> Wouldn't it be good enough to define the 'WITHIN' as expecting a
> unique-constraint name rather than an index name (even though those
> happen to be the same strings)?
>
> I think constraints are part of the logical definition of the database,
> and a new storage technique which doesn't use indexes should still have
> names for its unique constraints.
What about partial indexes? Indexes on expressions or functions calls?
.marko
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Woodcraft | 2014-10-12 12:47:31 | Re: UPSERT wiki page, and SQL MERGE syntax |
Previous Message | Ali Akbar | 2014-10-12 12:37:13 | Re: Function array_agg(array) |