Re: Bug found in psql interface

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

In response to

Browse pgsql-bugs by date

  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