DROP INDEX fails on overlength table names:

tgl=> CREATE UNIQUE INDEX MarketOrderHistory_sequenceNo_Index
tgl-> ON MarketOrderHistory USING btree (sequenceNo);
CREATE
tgl=> DROP INDEX MarketOrderHistory_sequenceNo_Index;
ERROR:  pg_ownercheck: class "marketorderhistory_sequenceno_index" not found
tgl=> DROP INDEX MarketOrderHistory_sequenceNo_I;
DROP

Evidently DROP INDEX is using a second-rate way of reducing the given
name to canonical form for comparisons.

Some further experimentation shows that CREATE TABLE won't let you
create a relation name >= 32 characters in the first place.  So there's
some inconsistency about what's done with overlength names.

It seems to me that we ought to have consistent treatment of long names,
and the treatment I like is the one that CREATE INDEX is using:
silently truncate the given name to what we can handle, and accept
it as long as the truncated form is unique.  This is the time-honored
way of handling overlength names in compilers, and it works well.

			regards, tom lane

Sun, 26 Jul 1998 11:10:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Minor bug: inconsistent handling of overlength names
On Sun, 26 Jul 1998, Tom Lane wrote:

> DROP INDEX fails on overlength table names:
> 
> tgl=> CREATE UNIQUE INDEX MarketOrderHistory_sequenceNo_Index
> tgl-> ON MarketOrderHistory USING btree (sequenceNo);
> CREATE
> tgl=> DROP INDEX MarketOrderHistory_sequenceNo_Index;
> ERROR:  pg_ownercheck: class "marketorderhistory_sequenceno_index" not found
> tgl=> DROP INDEX MarketOrderHistory_sequenceNo_I;
> DROP
> 
> Evidently DROP INDEX is using a second-rate way of reducing the given
> name to canonical form for comparisons.
> 
> Some further experimentation shows that CREATE TABLE won't let you
> create a relation name >= 32 characters in the first place.  So there's
> some inconsistency about what's done with overlength names.
> 
> It seems to me that we ought to have consistent treatment of long names,
> and the treatment I like is the one that CREATE INDEX is using:
> silently truncate the given name to what we can handle, and accept
> it as long as the truncated form is unique.  This is the time-honored
> way of handling overlength names in compilers, and it works well.

Same thing goes for user-names. I recently created a user named (for the 
sake of example) '1234567890', using CREATE USER. No complaints here, but 
trying to connect with user '1234567890' fails. You can connect with 
'12345678'.

Maarten

_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
|                   Department of Electrical Engineering                    |
|           Computer Architecture and Digital Technique section             |
|                          M.Boekhold@et.tudelft.nl                         |
-----------------------------------------------------------------------------


Sun, 26 Jul 1998 21:43:17 +0200 (MET DST)
Maarten Boekhold <maartenb@dutepp0.et.tudelft.nl>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names
I believe Tom Lane has fixed this.


> On Sun, 26 Jul 1998, Tom Lane wrote:
> 
> > DROP INDEX fails on overlength table names:
> > 
> > tgl=> CREATE UNIQUE INDEX MarketOrderHistory_sequenceNo_Index
> > tgl-> ON MarketOrderHistory USING btree (sequenceNo);
> > CREATE
> > tgl=> DROP INDEX MarketOrderHistory_sequenceNo_Index;
> > ERROR:  pg_ownercheck: class "marketorderhistory_sequenceno_index" not found
> > tgl=> DROP INDEX MarketOrderHistory_sequenceNo_I;
> > DROP
> > 
> > Evidently DROP INDEX is using a second-rate way of reducing the given
> > name to canonical form for comparisons.
> > 
> > Some further experimentation shows that CREATE TABLE won't let you
> > create a relation name >= 32 characters in the first place.  So there's
> > some inconsistency about what's done with overlength names.
> > 
> > It seems to me that we ought to have consistent treatment of long names,
> > and the treatment I like is the one that CREATE INDEX is using:
> > silently truncate the given name to what we can handle, and accept
> > it as long as the truncated form is unique.  This is the time-honored
> > way of handling overlength names in compilers, and it works well.
> 
> Same thing goes for user-names. I recently created a user named (for the 
> sake of example) '1234567890', using CREATE USER. No complaints here, but 
> trying to connect with user '1234567890' fails. You can connect with 
> '12345678'.
> 
> Maarten
> 
> _____________________________________________________________________________
> | TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
> |                   Department of Electrical Engineering                    |
> |           Computer Architecture and Digital Technique section             |
> |                          M.Boekhold@et.tudelft.nl                         |
> -----------------------------------------------------------------------------
> 
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sat, 22 Aug 1998 06:54:09 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I believe Tom Lane has fixed this.
>> On Sun, 26 Jul 1998, Tom Lane wrote:
>>>> DROP INDEX fails on overlength table names:

No, I have *not* fixed it, I only complained about it ;-).

I like your idea of truncating names to 31 characters in the parser;
this should solve the problem globally.  (Most likely, if DROP INDEX
has a bug then the same bug may exist elsewhere as well.)

Is the limit 31 not 32?

			regards, tom lane

Sat, 22 Aug 1998 11:59:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > I believe Tom Lane has fixed this.
> >> On Sun, 26 Jul 1998, Tom Lane wrote:
> >>>> DROP INDEX fails on overlength table names:
> 
> No, I have *not* fixed it, I only complained about it ;-).
> 
> I like your idea of truncating names to 31 characters in the parser;
> this should solve the problem globally.  (Most likely, if DROP INDEX
> has a bug then the same bug may exist elsewhere as well.)
> 
> Is the limit 31 not 32?

31.  Used to be 32 around 6.0, but all the code to compare non-null
terminated strings in the backend just wasn't worth it.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sat, 22 Aug 1998 17:15:01 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names
> DROP INDEX fails on overlength table names:
> 
> tgl=> CREATE UNIQUE INDEX MarketOrderHistory_sequenceNo_Index
> tgl-> ON MarketOrderHistory USING btree (sequenceNo);
> CREATE
> tgl=> DROP INDEX MarketOrderHistory_sequenceNo_Index;
> ERROR:  pg_ownercheck: class "marketorderhistory_sequenceno_index" not found
> tgl=> DROP INDEX MarketOrderHistory_sequenceNo_I;
> DROP
> 
> Evidently DROP INDEX is using a second-rate way of reducing the given
> name to canonical form for comparisons.
> 
> Some further experimentation shows that CREATE TABLE won't let you
> create a relation name >= 32 characters in the first place.  So there's
> some inconsistency about what's done with overlength names.
> 
> It seems to me that we ought to have consistent treatment of long names,
> and the treatment I like is the one that CREATE INDEX is using:
> silently truncate the given name to what we can handle, and accept
> it as long as the truncated form is unique.  This is the time-honored
> way of handling overlength names in compilers, and it works well.

OK. I have modified scan.l so it now truncates identifiers over
NAMEDATALEN, so this should fix it.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Fri, 28 Aug 1998 22:36:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > I believe Tom Lane has fixed this.
> >> On Sun, 26 Jul 1998, Tom Lane wrote:
> >>>> DROP INDEX fails on overlength table names:
> 
> No, I have *not* fixed it, I only complained about it ;-).
> 
> I like your idea of truncating names to 31 characters in the parser;
> this should solve the problem globally.  (Most likely, if DROP INDEX
> has a bug then the same bug may exist elsewhere as well.)
> 
> Is the limit 31 not 32?

Done.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Fri, 28 Aug 1998 22:55:53 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Minor bug: inconsistent handling of overlength names