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 i
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:
>
> https://wiki.postgresql
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 address when I hit 'Reply
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 list. It's not doing
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 returns a value
>>> o
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 w
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 a
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
Steven:
On Thu, Feb 8, 2018 at 10:52 PM, Steven Hirsch 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 li
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 returns NULL. As
> > such, shouldn't the outer cur
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
> imagine a rationale for th
On Thu, 8 Feb 2018, David G. Johnston wrote:
new_db=# \dfS+ currval
List of functions
Schema | Name | Result data type | Argument data types | Type |
Volatility | Parallel | Owner | Security | Access privileges | Language
| Source code | Des
cription
+-+-
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
>> installation (in public).
>>
>>
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 "pg_catalog", not
"public" ...
??
Al
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.
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 returns NULL.
>> So, where is the '0
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 currval(
pg_get_serial_seq
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
---+-+--
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
> set_type_definition','def_id'))
>
> ? I've a
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| student_att
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 seque
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 sequence
"udm_asset_type_definition_def_id_seq" is
On 02/08/2018 10:45 AM, Steven Hirsch wrote:
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/functi
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
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, make a typo, go over it
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:
>>
>> udm_asset_type_definition_def_id_seq21
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 bel
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 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 different. As requested by others, try posting the
>>
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_seq21 1 1
9223372036854775807 1 1 32 false true
SELECT currval('udm_asset_type_definition_id_s
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 different. As requested by others, try posting the
>>> SQL code chunks, more eyeballs make bugs shallower ( it's happened
>>
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
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
colleague, she immediately points to it )
Fa
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 transaction control - only
> th
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 a
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,
> reading back the m
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 tab
37 matches
Mail list logo
