From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
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 16:53:25 |
Message-ID: | 9936.1124124805@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> See "Identifiers and Key Words" in the "SQL Syntax" chapter:
> "The system uses no more than NAMEDATALEN-1 characters of an identifier;
> longer names can be written in commands, but they will be truncated. By
> default, NAMEDATALEN is 64 so the maximum identifier length is 63."
This limit also applies to operator names, and I just noticed that
scan.l isn't enforcing the limit for operators. In a build with asserts
enabled this leads to an assertion failure :-(
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.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oluwatope Akinniyi | 2005-08-15 17:58:14 | Re: ~/pgpass |
Previous Message | Richard Huxton | 2005-08-15 16:24:30 | Re: error inserting big files in DB. |