Re: Varchar standard compliance

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Varchar standard compliance
Дата
Msg-id Pine.LNX.4.21.0011171652590.789-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: Varchar standard compliance  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Varchar standard compliance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane writes:

> > Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
> > incorrectly interpreted as VARCHAR(<infinity>).  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 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.

It doesn't make much sense to me either, but it's consistent with the
overall SQL attitude of "no anythings of possibly unlimited length".

If we want to keep this, then there would really be no difference between
VARCHAR and TEXT, right?

I'm not partial to either side, but I wanted to know what the bit types
should do.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Coping with 'C' vs 'newC' function language names
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: Coping with 'C' vs 'newC' function language names