Re: Bug found in psql interface - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: Bug found in psql interface
Date
Msg-id 200208271541.g7RFf7U26035@candle.pha.pa.us
Whole thread Raw
In response to Bug found in psql interface  (Tony Griffiths <griffitt@cs.man.ac.uk>)
List pgsql-bugs
In 7.3, NAMEDATALEN is going to be 64, and your example does work there:

    test=> create table City_setregions_bds_regions_ass_rel(x int);
    CREATE TABLE
    test=> \d City_setregions_bds_regions_ass_rel
    Table "public.city_setregions_bds_regions_ass_rel"
     Column |  Type   | Modifiers
    --------+---------+-----------
     x      | integer |

    test=> create table City_setregions_bds_regions_ass_rel(x int);

My guess is that maybe we had some hard-coded limits in 7.1.2.  You
should be OK in 7.2, and certainly in 7.3.

---------------------------------------------------------------------------

Tony Griffiths wrote:
> Short Description
> Inconsistency in the way that psql handles long names
>
> Long Description
> PostgreSQL version 7.1.3
> OS: RedHat Linux 6.2
>
> I compiled this version of postgresql from source, with the NAMEDATALEN
> variable set to 512. All works ok, apart from when I use
> the psql interactive terminal, and type:
>
> \d City_setregions_bds_regions_ass_rel
>
> at the command line, where City_setregions_bds_regions_ass_rel is the
> name of a table that exploits the longer names. The terminal reports:
>
> Did not find any relation named "city_setregions_bds_regions_ass_".
>
> It therefore looks like the \d command is not picking up the longer
> NAMEDATALEN at compile time.
>
> Tony
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-bugs by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Bug #749: one NULL function parameter makes all other
Next
From: Bruce Momjian
Date:
Subject: Re: JDBC timestamp does not understand [-]infinity