From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Question about the NAME type used in pg_proc and pg_class |
Date: | 2005-08-15 19:10:08 |
Message-ID: | 20050815191006.GA23955@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Aug 15, 2005 at 12:53:25PM -0400, Tom Lane wrote:
>
> regression=# select 1 *********************************************************************************** 2;
> server closed the connection unexpectedly
>
> with this in the log:
> TRAP: FailedAssertion("!(keylen < 64)", File: "hashfunc.c", Line: 129)
>
> I believe that there would be no real ill effect in a non-assertion
> build, it would just say it couldn't find the operator. Too lazy to
> recompile that way to find out though.
Confirmed. The following is from REL8_0_STABLE built without assertions:
test=> select 1 *********************************************************************************** 2;
ERROR: operator does not exist: integer *********************************************************************************** integer
HINT: No operator matches the given name and argument type(s). You may need to add explicit type casts.
> I kinda think that truncation isn't a real sensible way to deal with
> overly long operator names anyway, and that throwing an ERROR would be
> more reasonable; if the scanner thinks it is looking at an 80-character
> operator name, you've probably messed up the syntax somewhere along the
> line. Comments?
An error sounds reasonable to me.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | CSN | 2005-08-15 19:14:16 | converting curly apostrophes to standard apostrophes |
Previous Message | Magnus Hagander | 2005-08-15 19:00:54 | Re: Linux Postgres authentication against active directory |