Do we still need these NOTICEs?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Do we still need these NOTICEs?
Дата
Msg-id 9273.1026860009@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Do we still need these NOTICEs?  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Re: Do we still need these NOTICEs?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
I am considering removing the following notices/warnings, since they
seem to be unnecessary in the brave new world of dependencies:

* The one about dropping a built-in function; you can't do it anyway.

regression=# drop function now();
WARNING:  Removing built-in function "now"
ERROR:  Cannot drop function now because it is required by the database system
regression=#

* The one about creating implicit triggers for FOREIGN KEY constraints:

regression=# create table bar (f1 int references foo);
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE TABLE
regression=#

Since those triggers (a) will be auto-dropped when you drop the
constraint, and (b) can't be dropped without dropping the constraint,
this notice seems like it's just noise now.

regression=# \d bar        Table "bar"Column |  Type   | Modifiers
--------+---------+-----------f1     | integer |
Triggers: RI_ConstraintTrigger_140127

regression=# drop trigger "RI_ConstraintTrigger_140127" on bar;
ERROR:  Cannot drop trigger RI_ConstraintTrigger_140127 on table bar because constraint $1 on table bar requires it
 You may drop constraint $1 on table bar instead
 
regression=# alter table bar drop constraint "$1";
ALTER TABLE
regression=# \d bar        Table "bar"Column |  Type   | Modifiers
--------+---------+-----------f1     | integer |

regression=#

* The ones about implicit indexes for primary key/unique constraints
and about implicit sequences for SERIAL columns also seem unnecessary
now --- as with the trigger case, you can't drop the implicit object
directly anymore.  However, the messages do convey some useful
information, namely the exact name that was assigned to the index or
sequence.  So I'm undecided about removing 'em.  The sequence message
seems particularly useful since people do often want to refer directly
to the sequence in manual nextval/currval commands.  OTOH psql's \d is a
perfectly reasonable way to get the sequence and index names if you need
'em.  Moreover, that still works after the fact whereas a NOTICE soon
disappears from sight.

Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Future of src/utils
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: DROP COLUMN