Search Postgresql Archives

Re: Odd behavior with 'currval'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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_attendance_attendance_id_seq
last_value    | bigint  | 39590
start_value   | bigint  | 1
increment_by  | bigint  | 1
max_value     | bigint  | 9223372036854775807
min_value     | bigint  | 1
cache_value   | bigint  | 1
log_cnt       | bigint  | 0
is_cycled     | boolean | f
is_called     | boolean | t
Owned by: public.student_attendance.attendance_id


Assuming you showed the complete output I am not seeing the Owned by: for your sequence. I would do the \d on one of your sequences that 'works', I am guessing you will see Owned by: .

To correct see:

https://www.postgresql.org/docs/10/static/sql-altersequence.html

"OWNED BY table_name.column_name
OWNED BY NONE

The OWNED BY option causes the sequence to be associated with a specific table column, such that if that column (or its whole table) is dropped, the sequence will be automatically dropped as well. If specified, this association replaces any previously specified association for the sequence. The specified table must have the same owner and be in the same schema as the sequence. Specifying OWNED BY NONE removes any existing association, making the sequence “free-standing”.

Agggh.  That's it!  I'll fix the ownership.

So, a few questions:

1. How on earth did this happen? I do not recall doing any manual fiddling with either database - they were (as far as I know) built from the same DDL. We may never have an answer for this. Being human, who knows what I may or may not have done 4 months ago...

But,

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 the current behavior.

THANKS to everyone who chimed in on this. I was beginning to think I was losing my marbles.

--

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux