Re: Odd behavior with 'currval'
От | Steven Hirsch |
---|---|
Тема | Re: Odd behavior with 'currval' |
Дата | |
Msg-id | alpine.DEB.2.20.1802081443480.5809@z87 обсуждение исходный текст |
Ответ на | Re: Odd behavior with 'currval' ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Odd behavior with 'currval'
|
Список | pgsql-general |
On Thu, 8 Feb 2018, David G. Johnston wrote: > On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch <snhirsch@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_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? --
В списке pgsql-general по дате отправления: