Re: UPSERT wiki page, and SQL MERGE syntax - Mailing list pgsql-hackers

From Matthew Woodcraft
Subject Re: UPSERT wiki page, and SQL MERGE syntax
Date
Msg-id m1dt94$r0j$1@ger.gmane.org
Whole thread Raw
In response to Re: UPSERT wiki page, and SQL MERGE syntax  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
On 2014-10-12 13:40, Marko Tiikkaja wrote:
> 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?

On this theory, you'd be allowed to use them with 'WITHIN' (or whatever
it would be called) if and when PostgreSQL gains the ability to create
and manage them using a form of the CONSTRAINT clause.

-M-





pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Next
From: Sawada Masahiko
Date:
Subject: Proposal : REINDEX SCHEMA