On Thu, Feb 8, 2018 at 12:51 PM, Steven Hirsch <snhir...@gmail.com> wrote:
> On Thu, 8 Feb 2018, David G. Johnston wrote:
>
> On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch <snhir...@gmail.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?
>>
>
> 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.
