From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Steven Hirsch <snhirsch(at)gmail(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Odd behavior with 'currval' |
Date: | 2018-02-08 19:34:37 |
Message-ID: | CAKFQuwYOid4vqN6abpxS=VrrYnt3PBnmvSF+Lk317cuL_jW32w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch <snhirsch(at)gmail(dot)com> wrote:
> On a hunch, I tried 'SELECT currval(NULL)' to see if it returned '0', but
> that too returns NULL. So, where is the '0' coming from when I do:
>
> SELECT currval( pg_get_serial_sequence('udm_as
> set_type_definition','def_id'))
>
> ? I've already established that the inner expression evaluates to NULL!
This is indeed unusual...to be specific here pg_get_serial_sequence
returns null in lieu of an error for being unable to locate the indicated
sequence. currval is returning null because it is defined "STRICT" and so
given a null input it will always return null. currval itself, when
provided a non-null input, is going to error or provide a number (which
should never be zero...).
I'm wondering whether someone didn't like the fact that currval errors and
instead wrote a overriding function that instead returns zero?
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2018-02-08 19:35:08 | Re: Odd behavior with 'currval' |
Previous Message | Steven Hirsch | 2018-02-08 19:12:07 | Re: Odd behavior with 'currval' |