On Thu, May 10, 2018 at 12:16 PM, Martín Marqués
wrote:
> 2018-05-10 16:04 GMT-03:00 Eugene Wang :
> > Unique Constraint and Unique Index should be the same in this
> single-column
> > case, right?
>
> The unique index is what enforces the uniqueness of the field with a
> UNIQUE constraint, but a
2018-05-10 16:04 GMT-03:00 Eugene Wang :
> Unique Constraint and Unique Index should be the same in this single-column
> case, right?
The unique index is what enforces the uniqueness of the field with a
UNIQUE constraint, but a unique index is not necessarily a constraint.
For example, you can us
Eugene Wang wrote:
> Unique Constraint and Unique Index should be the same in this single-column
> case, right?
>
> Because, according to CONSTRAINT page in Postgres Documentation, Unique
> Constraint on single column is realized as Unique B-TREE index.
>
> I have just realized that it is still a
Unique Constraint and Unique Index should be the same in this single-column
case, right?
Because, according to CONSTRAINT page in Postgres Documentation, Unique
Constraint on single column is realized as Unique B-TREE index.
I have just realized that it is still a btree index, but I think this
ex
Peter Eisentraut writes:
> I think that last part isn't actually written down anywhere. (It only
> states the converse.) How about a clarification like this:
> @@ -271,7 +271,10 @@ Notes
> and not use grouping or ORDER BY). Cursors
> that are not simply updatable might work, or mig
On 5/9/18 22:57, Tom Lane wrote:
> I think you misread that note: it says nothing about what is allowed
> in DECLARE CURSOR per se. It is talking about whether you can apply
> UPDATE/DELETE WHERE CURRENT OF to that cursor. Moreover, what it says
> is that if you use FOR UPDATE then such an UPDATE
