Re: Do we still need these NOTICEs?

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

In response to

Browse pgsql-hackers by date

  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