Re: Odd behavior with 'currval'
От | Steven Hirsch |
---|---|
Тема | Re: Odd behavior with 'currval' |
Дата | |
Msg-id | alpine.DEB.2.20.1802081403270.5809@z87 обсуждение исходный текст |
Ответ на | Re: Odd behavior with 'currval' (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Odd behavior with 'currval'
Re: Odd behavior with 'currval' |
Список | pgsql-general |
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. --
В списке pgsql-general по дате отправления: