From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tony Griffiths <griffitt(at)cs(dot)man(dot)ac(dot)uk> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug found in psql interface |
Date: | 2002-08-27 15:41:07 |
Message-ID: | 200208271541.g7RFf7U26035@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)postgresql(dot)org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-27 16:42:16 | Re: JDBC timestamp does not understand [-]infinity |
Previous Message | Stephan Szabo | 2002-08-27 15:20:22 | Re: Bug #749: one NULL function parameter makes all other |