Re: Catching unique_violation exception on specific column/index

From: Alexey Dokuchaev <danfe(at)nsu(dot)ru>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Catching unique_violation exception on specific column/index
Date: 2018-06-11 18:21:00
Message-ID: 20180611182059.GA60559@regency.nsu.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jun 11, 2018 at 01:26:16PM +0200, Thomas Kellerer wrote:
> If that functionality is an important part of your code, you should
> consider upgrading to 10 (or 9.6 if your are really conservative)
> rather sooner than later.

Oh well, fair enough. As much as I'd love to stick to the lowest
supported (and sometimes even unsupported) versions, ON CONFLICT is
indeed very handy, esp. since I have a few UPSERT's implemented the
old way already (via catching the "unique_violation" exception).

Shall I update to 9.6/10, I have a bit off-topic (to the original
subject) question: right now, when I need to get the length of an
array (never multidimensional), I do this:

coalesce(array_length(foo, 1), 0);

In 9.4+, I can call cardinality(). I'm a bit hesitant: is doing so
semantically correct, or should I still do coalesce(..., 0) in this
case? This is not about the outcome, it's whether cardinality() is
semantically correct to obtain the number of the array items, or it
was introduced for other means?

./danfe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2018-06-11 18:31:42 Re: Catching unique_violation exception on specific column/index
Previous Message Andres Freund 2018-06-11 17:29:25 Re: pg_upgrade and wraparound