Peter Eisentraut <peter_e@gmx.net> writes:
>> On what grounds do you claim that behavior is incorrect?
> Because SQL says so:
> <character string type> ::=
> CHARACTER [ <left paren> <length> <right paren> ]
> | CHAR [ <left paren> <length> <right paren> ]
> | CHARACTER VARYING <left paren> <length> <right paren>
> | CHAR VARYING <left paren> <length> <right paren>
> | VARCHAR <left paren> <length> <right paren>
> 4) If <length> is omitted, then a <length> of 1 is implicit.
Well, what that actually says is that CHAR means CHAR(1). The syntax
does not allow VARCHAR without (n), so the thing we are noncompliant
on is not what we consider the default n to be, but whether there is
a default length for varchar at all. The spec is not offering one.
I don't particularly want to enforce the spec's position that leaving
off (n) is illegal, and given the choice between defaulting to
VARCHAR(1) or VARCHAR(large), I'll take the second. The second one
at least has some usefulness...
> If we want to keep this, then there would really be no difference between
> VARCHAR and TEXT, right?
There's no real difference between VARCHAR without a length limit and
TEXT, no.
> I'm not partial to either side, but I wanted to know what the bit types
> should do.
I'd be inclined to stick with our existing VARCHAR behavior just on
grounds of backwards compatibility. If you want to make the bit types
behave differently, I wouldn't say that's indefensible.
However, one advantage of treating BIT VARYING without (n) as unlimited
is that you'd have the equivalent functionality to TEXT without having
to make a third bit type...
regards, tom lane