Horton

Thread

  1. Minor bug: inconsistent handling of overlength names

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-07-26T15:10:51Z

    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

  2. Re: [HACKERS] Minor bug: inconsistent handling of overlength names

    Maarten Boekhold <maartenb@dutepp0.et.tudelft.nl> — 1998-07-26T19:43:17Z

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

  3. Re: [HACKERS] Minor bug: inconsistent handling of overlength names

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-22T10:54:09Z

    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)

  4. Re: [HACKERS] Minor bug: inconsistent handling of overlength names

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-29T02:36:38Z

    > 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)