Re: 6.5.2 create index bug?

|Can anybody verify whether this is a bug in 6.5.2? I compiled 6.5.2
|from sources, everything seemed OK.
|
|I created a table:
| CREATE TABLE TESTTBL (A int4);
|
|Then tried to create a unique index:
| CREATE UNIQUE INDEX TESTTBL0 ON TESTTBL (A);
|
|The above failed, but the following succeeded:
| CREATE UNIQUE INDEX TESTTBL_0 ON TESTTBL (A);
|
|Thank you.

Sorry, I know it's bad form to reply to oneself.

Short Answer: No bug!

Full Story:
On Sept. 24, 1999 I untarred the version 6.5.2 tarball and followed the
compile and install instructions in the INSTALL file. I started the
postmaster without any problem and ran the psql test SELECT statement in
the INSTALL file. I did NOT run the regression tests (mistake #1)
because there were no problems during the compile, install, startup and
psql test.
I created a database and connected to it via ODBC (psqlodbc 6.04.0007)
and started a third party application without testing everything first
(mistake #2). The third party app ran for a little while then errored
out with an ODBC error 'Could not create index'. I started a psql
seesion and tried to create the index manually, I got the same error in
psql when I tried to create an index with the table name followed by any
number, but the index would create OK if there was an underscore between
the name and number. Since time was a little short, I ASSUMED (mistake
#3) it was a version 6.5.2 problem since I had created indexes like this
under 6.4.2. I deleted the 6.5.2 installation and installed the 6.4.2
RPMs from the RedHat 6.0 CD. The third party app then ran without
problems using the same ODBC driver and setup.
On Sept. 26, 1999 I thought I should tell someone about the 'bug' and
e-mailed the above message without further testing (mistake #4) or
saving the output and error messages from psql (mistake #5).
On Sept. 28, 1999 I uninstalled the RPMs and started over with 6.5.2.
This time I checked the compile and install logs and ran the regression
tests. I created a test database and tables, then created indexes that
failed before. Everything worked fine this time. I then ran the third
party application again without problems. I'm not sure what happened
the first time around, but it probably wasn't a postgres problem.

My apologies to the developers about the false bug report, I'll try to
be more careful in the future.