Re: Odd behavior with 'currval'

From: Steven Hirsch <snhirsch(at)gmail(dot)com>
To: "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:51:00
Message-ID: alpine.DEB.2.20.1802081443480.5809@z87
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 8 Feb 2018, David G. Johnston wrote:

> 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_asset_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?

Do you mean "someone" on the PostgreSQL development team - or "someone" at
my end? I can assure you there are no overriding functions in either
of my databases. I just double-checked this. The only 'currval'
procedure is the one defined at installation (in public).

Looks like I may have encountered a legitimate bug?

--

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2018-02-08 19:54:28 Re: Odd behavior with 'currval'
Previous Message Adrian Klaver 2018-02-08 19:35:08 Re: Odd behavior with 'currval'