Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is there a reason why the conversion from CHAR to CHAR(1) is done in
> analyze.c:transformColumnType rather than right in the
> grammar?
Well, transformColumnType does database access, which is verboten during
the grammar phase. (The grammar has to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> On what grounds do you claim that behavior is incorrect?
> Because SQL says so:
> ::=
> CHARACTER []
> | CHAR []
> | CHARACTER VARYING
> | CHAR VARYING
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
> incorrectly interpreted as VARCHAR(). Any reason for that,
> besides the fact that it of course makes much more sense than VARCHAR(1)?
On what grounds do you claim that behavior i
o: "PostgreSQL Development" <[EMAIL PROTECTED]>
Sent: Thursday, November 16, 2000 10:16 AM
Subject: [HACKERS] Varchar standard compliance
> Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
> incorrectly interpreted as VARCHAR(). Any reason for that,
>
Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
incorrectly interpreted as VARCHAR(). Any reason for that,
besides the fact that it of course makes much more sense than VARCHAR(1)?
Additionally, neither CHAR nor VARCHAR seem to bark on too long input,
they just truncate silen
