On 11/21/2012 10:00:11 PM, Karl O. Pinc wrote:
> On 11/21/2012 02:12:26 PM, Robert Haas wrote:
> > On Sat, Nov 17, 2012 at 1:22 AM, Peter Eisentraut <peter_e@gmx.net>
> > wrote:
> > > On Mon, 2012-11-12 at 11:42 -0600, Karl O. Pinc wrote:
> > >> Could ALTER TABLE use an option to drop the
> > >> primary key constraint? I needed to do that,
> > >> found it was not obvious, and this lead me to
> > >> try to improve things.
> > >
> > > That could be useful, I think. But it might open a can of worms.
> >
> > Would the new option be syntactic sugar around ALTER TABLE ... DROP
> > CONSTRAINT "put_the_name_of_the_primary_key_here"?
>
> This sounds nice to me,
No, wait. If constraint "name_of_primary_key" is an internal
and is to change over time, how do you deal with dropping,
now, a primary key constraint that was created, then, before
some change to the internal name. And you wouldn't want
to accidentally remove a user-created constraint
that just happened to have the same name as the internal
primary key constraint name, especially in the case
where there's a real primary key constraint created
under an old naming convention.
Changes to the primary key constraint naming convention
would have to require a db dump/restore on pg upgrade
to the new version, or something else that changes
the primary key constraint names.
(And then I'm not sure what would
happen if a user was, before upgrading, using a constraint name
that was the new default.) And the changing of
the internal constraint name would have had to have
always previously caused a name change in existing
pg dbs or else dbs created long ago could today
have primary key constraint names following old
conventions, raising the concern at top.
I'm sorry to waste your time if these are obvious
issues.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
