Re: Odd behavior with 'currval'

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.

In response to

Responses

Browse pgsql-general by date

  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'