On Thu, 8 Feb 2018, David G. Johnston wrote:
On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch <snhirsch@xxxxxxxxx> 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?
Yes, I meant locally.
If you can generate a standalone reproducing test script it would indeed be treated as a bug report and looked into. It would ideally be in psql, not a Java program.
David J.
