Re: Non-colliding auto generated names

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Non-colliding auto generated names
Date: 2003-02-18 15:03:17
Message-ID: 20030218225522.G57144-100000@houston.familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> THe point is that right now, if you know the CREATE TABLE command, then
> you can compute exactly what index names it will assign --- no outside
> knowledge about the previous state of the database is required.

Yes, but how is that at all helpful? I mean, you can know perfectly well
what the database might assign the name, but you still will not know if
it's going to conflict or not! You still have to try it to see if it
fails and if it fails, you need to choose a new name.

> I'm not sure how significant that really is to anyone, but it is
> something that we'd be giving up.

I can't think of any reason someone would be _relying_ in their app on the
name that the database might generate for them...we should ask -general.

But imagine what we're gaining...

I mean, imagine the poor newbie who goes to create a table with a SERIAL
column. It fails with a conflict. The error message is cryptic, going on
about 'sequences'. The newbie's going 'what's a sequence, i haven't said
anything about a sequence'. Then they try renaming a table to something
else and then create a table with the same name as the renamed table and
it fails for some mysterious reason!

If we wanted to stay consistent, then we should be renaming the constraint
indexes whenever the table is renamed!

Surely, surely anyone who relies on auto-generated names will just be
specifying the name explicitly anyway...?

> And as I said, I don't have a better answer. I'm just expressing
> vague unease, in hopes that it might spur someone to think of another
> way. I'm willing to go with this way if we don't find another.

There is a vague possibility that someone might be using it, but I think
it's very unlikely....

Chris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-18 15:21:57 Re: Detecting corrupted pages earlier
Previous Message Christopher Kings-Lynne 2003-02-18 14:54:57 Re: pg environment? metadata?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-02-18 15:07:36 Re: pg_avd
Previous Message greg 2003-02-18 14:45:44 Re: FAQ addition: deleteing all but one unique row