On 06/11/2018 11:21 AM, Alexey Dokuchaev wrote:
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.
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
s
Alexey Dokuchaev schrieb am 11.06.2018 um 12:58:
>>> I have a table with several UNIQUE and CHECK constraints. One of these
>>> UNIQUE constraints actually *can* be violated -- not on the table level,
>>> of course, but on the application level -- meaning, if the entry with
>>> particular foo_key
Am 11.06.2018 um 12:58 schrieb Alexey Dokuchaev:
What's wrong with:
INSERT ...
ON CONFLICT (foo_key) DO NOTHING
Nothing I guess, except that it is available since 9.5 (right?), and I try
to stay compatible with 9.3. Sorry for not saying this in the first place.
./danfe
... 9.3 wil
On Mon, Jun 11, 2018 at 12:30:13PM +0200, Thomas Kellerer wrote:
> Alexey Dokuchaev schrieb am 11.06.2018 um 12:10:
> > I have a table with several UNIQUE and CHECK constraints. One of these
> > UNIQUE constraints actually *can* be violated -- not on the table level,
> > of course, but on the appl
Alexey Dokuchaev schrieb am 11.06.2018 um 12:10:
> I have a table with several UNIQUE and CHECK constraints. One of these
> UNIQUE constraints actually *can* be violated -- not on the table level,
> of course, but on the application level -- meaning, if the entry with
> particular foo_key is alrea
On Mon, Jun 11, 2018 at 05:10:33PM +0700, Alexey Dokuchaev wrote:
> The usual approach ("EXCEPTION WHEN unique_violation THEN ... END") does
> not really cut it because I want to catch unique_violation only when it
> happens on "foo_key", and still rightfully complain on others. However,
> there i
Hi there,
I have a table with several UNIQUE and CHECK constraints. One of these
UNIQUE constraints actually *can* be violated -- not on the table level,
of course, but on the application level -- meaning, if the entry with
particular foo_key is already in there, do not throw an exception, just
s
