Re: Odd behavior with 'currval'

On Fri, 9 Feb 2018, Francisco Olarte wrote: I was trying to be careful and changed the address manually for all messages except this one. Do not bother with that. The style in this list is to just reply to all, so the people that are participating in the thread can get a copy of the messages

Re: Odd behavior with 'currval'

Adrian: On Fri, Feb 9, 2018 at 7:17 PM, Adrian Klaver wrote: > On 02/09/2018 09:43 AM, Francisco Olarte wrote: >> It's probably because this list headers are "old school", without >> those newflangled thingied. > I believe with the change to PGLister that changed:

Re: Odd behavior with 'currval'

On 02/09/2018 09:43 AM, Francisco Olarte wrote: Steven: On Fri, Feb 9, 2018 at 6:33 PM, Steven Hirsch wrote: Ah, blast... Apologies to everyone concerned. I need to understand why my mail reader (Alpine on Linux) insists on defaulting to the original poster's e-mail

Re: Odd behavior with 'currval'

Steven: On Fri, Feb 9, 2018 at 6:33 PM, Steven Hirsch wrote: > Ah, blast... Apologies to everyone concerned. I need to understand why my > mail reader (Alpine on Linux) insists on defaulting to the original poster's > e-mail address when I hit 'Reply' rather than the group

Re: Odd behavior with 'currval'

Steven: On Fri, Feb 9, 2018 at 5:58 PM, Steven Hirsch wrote: > On Fri, 9 Feb 2018, Francisco Olarte wrote: >> This may sound a bit harsh but: >>> The culprit is in the JDBC domain, NOT PostgreSQL! According to the >>> documentation I found, the ResultSet 'getLong()' method

Re: Odd behavior with 'currval'

On Fri, 9 Feb 2018, Adrian Klaver wrote: I remember seeing it, so I went back to look at the message. Turns out you sent it to me only. Unfortunately I am not a Java programmer so I did not catch the error. For the record: Ah, blast... Apologies to everyone concerned. I need to understand

Re: Odd behavior with 'currval'

On 02/09/2018 08:58 AM, Steven Hirsch wrote: On Fri, 9 Feb 2018, Francisco Olarte wrote: This may sound a bit harsh but: The culprit is in the JDBC domain, NOT PostgreSQL!  According to the documentation I found, the ResultSet 'getLong()' method returns a value of zero when it sees NULL as

Re: Odd behavior with 'currval'

On Fri, 9 Feb 2018, Francisco Olarte wrote: This may sound a bit harsh but: The culprit is in the JDBC domain, NOT PostgreSQL! According to the documentation I found, the ResultSet 'getLong()' method returns a value of zero when it sees NULL as an input. Why the JDBC libs don't treat this as

Re: Odd behavior with 'currval'

On Fri, Feb 9, 2018 at 8:27 AM, Francisco Olarte wrote: > On Thu, Feb 8, 2018 at 8:12 PM, Steven Hirsch wrote: > . > > > 2. Why is the currval() function being so blasted dumb? If > > 'pg_get_serial_sequence' cannot resolve the sequence, it

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 8:12 PM, Steven Hirsch wrote: . > 2. Why is the currval() function being so blasted dumb? If > 'pg_get_serial_sequence' cannot resolve the sequence, it returns NULL. As > such, shouldn't the outer currval() also be returning NULL? I cannot >

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 2:22 PM, Steven Hirsch wrote: > On Thu, 8 Feb 2018, David G. Johnston wrote: > > On Thu, Feb 8, 2018 at 12:54 PM, David G. Johnston < >> david.g.johns...@gmail.com> wrote: >> The only 'currval' procedure is the one defined at >>

Re: Odd behavior with 'currval'

On Thu, 8 Feb 2018, David G. Johnston wrote: On Thu, Feb 8, 2018 at 12:54 PM, David G. Johnston wrote:  The only 'currval' procedure is the one defined at installation (in public). ​So, the installed version of currval would be defined in

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 12:54 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > The only 'currval' procedure is the one defined at installation (in >> public). >> > ​So, the installed version of currval would be defined in "pg_catalog", not "public" ... David J. ​

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 12:51 PM, Steven Hirsch wrote: > On Thu, 8 Feb 2018, David G. Johnston wrote: > > On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch wrote: >> On a hunch, I tried 'SELECT currval(NULL)' to see if it returned >> '0', but that too

Re: Odd behavior with 'currval'

On Thu, 8 Feb 2018, David G. Johnston wrote: On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch 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

Re: Odd behavior with 'currval'

On 02/08/2018 11:12 AM, Steven Hirsch wrote: On Thu, 8 Feb 2018, Adrian Klaver wrote: hplc=> \d student_attendance_attendance_id_seq     Sequence "public.student_attendance_attendance_id_seq"    Column |  Type   |    Value

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 10:58 AM, Steven Hirsch 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 >

Re: Odd behavior with 'currval'

On Thu, 8 Feb 2018, Adrian Klaver wrote: hplc=> \d student_attendance_attendance_id_seq Sequence "public.student_attendance_attendance_id_seq" Column | Type |Value ---+-+-- sequence_name | name|

Re: Odd behavior with 'currval'

On 02/08/2018 10:54 AM, Steven Hirsch wrote: On Thu, 8 Feb 2018, Adrian Klaver wrote: SELECT currval('udm_asset_type_definition_id_seq'); Arrgh my mistake, the above should have been SELECT currval('udm_asset_type_definition_def_id_seq'); [Code: , SQL State: 55000]  ERROR: currval of

Re: Odd behavior with 'currval'

On Thu, 8 Feb 2018, Melvin Davidson wrote: I believe your problem is in your usage. In order for currval(regclass) to work, you must first do a SELECT nextval(regclass) in your _current transaction_! https://www.postgresql.org/docs/9.6/static/functions-sequence.html I AM doing that. It is

Re: Odd behavior with 'currval'

Steven: On Thu, Feb 8, 2018 at 6:58 PM, Steven Hirsch wrote: > On Thu, 8 Feb 2018, Francisco Olarte wrote: >> Something must be different. As requested by others, try posting the >> SQL code chunks, more eyeballs make bugs shallower ( it's happened >> several times to me,

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 1:27 PM, Adrian Klaver wrote: > On 02/08/2018 10:20 AM, Steven Hirsch wrote: > >> On Thu, 8 Feb 2018, Adrian Klaver wrote: >> >> What if you do?: >>> >>> SELECT * FROM udm_asset_type_definition_def_id_seq; >>> >> >> I get: >> >>

Re: Odd behavior with 'currval'

On 02/08/2018 10:20 AM, Steven Hirsch wrote: On Thu, 8 Feb 2018, Adrian Klaver wrote: What if you do?: SELECT * FROM udm_asset_type_definition_def_id_seq; I get: udm_asset_type_definition_def_id_seq    21    1    1 9223372036854775807    1    1    32    false    true What does the

Re: Odd behavior with 'currval'

On 02/08/2018 10:20 AM, Steven Hirsch wrote: On Thu, 8 Feb 2018, Adrian Klaver wrote: What if you do?: SELECT * FROM udm_asset_type_definition_def_id_seq; I get: udm_asset_type_definition_def_id_seq    21    1    1 9223372036854775807    1    1    32    false    true SELECT

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 1:17 PM, Melvin Davidson wrote: > > > On Thu, Feb 8, 2018 at 1:09 PM, Adrian Klaver > wrote: > >> On 02/08/2018 09:58 AM, Steven Hirsch wrote: >> >>> On Thu, 8 Feb 2018, Francisco Olarte wrote: >>> >>> Something must be

Re: Odd behavior with 'currval'

On 02/08/2018 09:58 AM, Steven Hirsch wrote: On Thu, 8 Feb 2018, Francisco Olarte wrote: Something must be different. As requested by others, try posting the SQL code chunks, more eyeballs make bugs shallower ( it's happened several times to me, make a typo, go over it for half an hour, grab a

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 5:09 PM, Steven Hirsch wrote: > I have a body of code using JDBC to work with a PostgreSQL 9.6 database. All .. > The code being used in the failing case is not the slightest bit different > from the working cases in terms of structure and

Re: Odd behavior with 'currval'

On 02/08/2018 08:09 AM, Steven Hirsch wrote: I have a body of code using JDBC to work with a PostgreSQL 9.6 database. All tables use 'SERIAL' or 'BIGSERIAL' types to generate ids.  All are working correctly in terms of using the next value as a default. However, reading back the most recently

Re: Odd behavior with 'currval'

On Thu, Feb 8, 2018 at 9:09 AM, Steven Hirsch wrote: > I have a body of code using JDBC to work with a PostgreSQL 9.6 database. > All tables use 'SERIAL' or 'BIGSERIAL' types to generate ids. All are > working correctly in terms of using the next value as a default. However,

Odd behavior with 'currval'

I have a body of code using JDBC to work with a PostgreSQL 9.6 database. All tables use 'SERIAL' or 'BIGSERIAL' types to generate ids. All are working correctly in terms of using the next value as a default. However, reading back the most recently applied (currval) value is failing for one