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

Tue, 16 Jul 2002 18:53:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Do we still need these NOTICEs?
> * 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


Wed, 17 Jul 2002 09:43:45 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Do we still need these NOTICEs?
Tom Lane wrote:
> 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:

Yep, remove them.

> 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=#

Remove.

> * 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.

I would remove them all.  If people complain, we can add them back in. 
Why not remove them and keep the diff on your machine somewhere.  If
we get complaints, we can re-add them.  We already get complaints about
people _not_ wanting to see them, and hence the request to disable
NOTICE messages in psql, which will be possible in 7.3.

Now that we have them auto-dropped, it is appropriate for them not to
appear during creation.  We mentioned them in the past specifically so
people would know they existed to drop them.  Now, they don't need to
know that anymore.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 16 Jul 2002 23:10:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Do we still need these NOTICEs?
Bruce Momjian wrote:
> Tom Lane wrote:
> 
>>I am considering removing the following notices/warnings, since they
>>seem to be unnecessary in the brave new world of dependencies:

I also agree with removing all of these.

>>* 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.

One thing I wondered about here -- is it still possible to use a 
sequence, which is autogenerated by a SERIAL column, as the default 
value for another table? If so, does this create another dependency to 
prevent dropping the sequence, and hence the original (creating) table also?

Joe



Tue, 16 Jul 2002 20:19:32 -0700
Joe Conway <mail@joeconway.com>
Re: Do we still need these NOTICEs?
Joe Conway wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > 
> >>I am considering removing the following notices/warnings, since they
> >>seem to be unnecessary in the brave new world of dependencies:
> 
> I also agree with removing all of these.
> 
> >>* 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.
> 
> One thing I wondered about here -- is it still possible to use a 
> sequence, which is autogenerated by a SERIAL column, as the default 
> value for another table? If so, does this create another dependency to 
> prevent dropping the sequence, and hence the original (creating) table also?

My guess is that the dependency code will now track it(?).  A harder
issue is if you use nextval() in the INSERT, there is no way for the
dependency code to know it is used by that table, so it will be dropped
if the parent table that created it is dropped.  In such cases, the
sequence should always be created manually or a DEFAULT defined, even if
you never use it as a default.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 16 Jul 2002 23:24:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Do we still need these NOTICEs?
Joe Conway <mail@joeconway.com> writes:
> One thing I wondered about here -- is it still possible to use a 
> sequence, which is autogenerated by a SERIAL column, as the default 
> value for another table?

Sure, same as before.

> If so, does this create another dependency to 
> prevent dropping the sequence, and hence the original (creating) table also?

As the code stands, no.  The other table's default would look like
	nextval('first_table_col_seq')
and the dependency deducer only sees nextval() and a string constant
in this.

Someday I'd like to see us support the Oracle-ish syntax
	first_table_col_seq.nextval
which would expose the sequence reference in a way that allows the
system to understand it during static examination of a query.

			regards, tom lane

Wed, 17 Jul 2002 00:10:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Do we still need these NOTICEs? 
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > One thing I wondered about here -- is it still possible to use a 
> > sequence, which is autogenerated by a SERIAL column, as the default 
> > value for another table?
> 
> Sure, same as before.
> 
> > If so, does this create another dependency to 
> > prevent dropping the sequence, and hence the original (creating) table also?
> 
> As the code stands, no.  The other table's default would look like
> 	nextval('first_table_col_seq')
> and the dependency deducer only sees nextval() and a string constant
> in this.
> 
> Someday I'd like to see us support the Oracle-ish syntax
> 	first_table_col_seq.nextval
> which would expose the sequence reference in a way that allows the
> system to understand it during static examination of a query.

OK, so creator tracks it, and referencers, even in DEFAULT, don't.  Good
to know and probably something we need to point out in the release
notes.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Jul 2002 01:29:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Do we still need these NOTICEs?