Re: "RETURNING PRIMARY KEY" syntax extension

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
Cc: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "RETURNING PRIMARY KEY" syntax extension
Date: 2014-06-11 00:26:00
Message-ID: 20140611002600.GQ8406@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-06-11 00:21:58 +0200, Vik Fearing wrote:
> On 06/09/2014 07:13 PM, Andres Freund wrote:
> > On 2014-06-09 13:42:22 +0200, Vik Fearing wrote:
> >> On 06/09/2014 09:06 AM, Gavin Flower wrote:
> >>> From memory all unique keys can be considered 'candidate primary keys',
> >>> but only one can be designated 'the PRIMARY KEY'.
> >>
> >> Almost. Candidate keys are also NOT NULL.
> >
> > The list actually is a bit longer. They also cannot be partial.
>
> What? AFAIK, that only applies to an index. How can the data itself be
> partial?

I don't follow? Gavin above talked about unique keys - which in postgres
you can create using CREATE UNIQUE INDEX. And if you make those partial
they can't be used for this purpose.

> > There's generally also the restriction that for some contexts - like
> > e.g. foreign keys - primary/candidate keys may not be deferrable..
>
> Again, what is deferrable data?

You can define primary/unique constraints to be deferrable. c.f. CREATE
TABLE docs.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-11 00:39:32 Re: "RETURNING PRIMARY KEY" syntax extension
Previous Message Robert Haas 2014-06-11 00:12:26 Re: Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller