From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org> |
Cc: | nbazin(at)ingenico(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] Bug #581: Sequence cannot be deleted |
Date: | 2002-02-12 20:48:09 |
Message-ID: | 24439.1013546889@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Brent Verner <brent(at)rcfile(dot)org> writes:
> ISTM it would make sense to expose the sequence naming logic via
> a builtin function, such as pg_serialseq(table,column)?
That might seem cleaner, but I think there's a hidden gotcha: it nails
down a presumption that the sequence name is a function of the table
name, column name, and nothing else. So I think it'd actually make it
harder rather than easier for us to make the sorts of changes we might
want to make in future. (F'r instance, we might add an OID into the
name to prevent collisions.)
I believe that the surprising-name problem will largely go away anyway
as soon as we get around to increasing the default NAMEDATALEN. With
a decent name length no one would ever see truncation in practice.
Also, of course, what we really want is for SERIAL sequences to get
dropped by themselves when the parent table is dropped, and then users
don't need to know what the generated sequence name is ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-02-12 21:14:56 | Re: Bug #584: postgresql will not build on Solaris with cc |
Previous Message | Isamary García | 2002-02-12 20:10:24 | createdb problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-02-12 21:29:01 | Re: Maintaining the list of release changes |
Previous Message | Brent Verner | 2002-02-12 20:09:28 | Re: [BUGS] Bug #581: Sequence cannot be deleted |