Re: UPSERT wiki page, and SQL MERGE syntax

From: Matthew Woodcraft <matthew(at)woodcraft(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Date: 2014-10-12 12:47:31
Message-ID: m1dt94$r0j$1@ger.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sawada Masahiko 2014-10-12 13:58:24 Proposal : REINDEX SCHEMA
Previous Message Marko Tiikkaja 2014-10-12 12:40:35 Re: UPSERT wiki page, and SQL MERGE syntax