From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Do we still need these NOTICEs? |
Date: | 2002-07-17 01:43:45 |
Message-ID: | GNELIHDDFBOCMGBFGEFOAECPCDAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> * 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=#
Get rid of it.
> * 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.
Yep - may as well.
> 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.
Hmmmm...undecided. I generally wouldn't care I guess, but some people
might...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2002-07-17 01:44:39 | Re: pg_views.definition |
Previous Message | Christopher Kings-Lynne | 2002-07-17 01:31:29 | Re: pg_views.definition |