On Sun, Nov 14, 2021 at 10:33:19AM +0800, Japin Li wrote: > > On Sat, 13 Nov 2021 at 23:42, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Japin Li <japi...@hotmail.com> writes: > >> postgres=# CREATE TABLE tbl (s varchar(2147483647)); > >> ERROR: length for type varchar cannot exceed 10485760 > >> LINE 1: CREATE TABLE tbl (s varchar(2147483647)); > >> ^ > > > >> postgres=# CREATE TABLE tbl (s varchar(2147483648)); > >> ERROR: syntax error at or near "2147483648" > >> LINE 1: CREATE TABLE tbl (s varchar(2147483648)); > >> ^ > > > > I'm having a very hard time getting excited about that. We could maybe > > switch the grammar production to use generic expr_list syntax for the > > typmod, like GenericType does. But that would just result in this: > > > > regression=# CREATE TABLE tbl (s "varchar"(2147483648)); > > ERROR: value "2147483648" is out of range for type integer > > LINE 1: CREATE TABLE tbl (s "varchar"(2147483648)); > > ^ > > > > which doesn't seem any less confusing for a novice who doesn't know > > that typmods are constrained to be integers. > > > > There might be something to be said for switching all the hard-wired > > type productions to use opt_type_modifiers and pushing the knowledge > > that's in, eg, opt_float out to per-type typmodin routines. But any > > benefit would be in reduction of the grammar size, and I'm dubious > > that it'd be worth the trouble. I suspect that overall, the resulting > > error messages would be slightly worse not better --- note for example > > the poorer placement of the error cursor above. A related example is > > > > regression=# CREATE TABLE tbl (s varchar(2,3)); > > ERROR: syntax error at or near "," > > LINE 1: CREATE TABLE tbl (s varchar(2,3)); > > ^ > > regression=# CREATE TABLE tbl (s "varchar"(2,3)); > > ERROR: invalid type modifier > > LINE 1: CREATE TABLE tbl (s "varchar"(2,3)); > > ^ > > > > That's explained by the comment in anychar_typmodin: > > > > * we're not too tense about good error message here because grammar > > * shouldn't allow wrong number of modifiers for CHAR > > > > and we could surely improve that message, but anychar_typmodin can't give > > a really on-point error cursor. > > > > Oh! I didn't consider this situation. Since the max size of varchar cannot > exceed 10485760, however, I cannot find this in documentation [1]. Is there > something I missed? Should we mention this in the documentation? > > [1] https://www.postgresql.org/docs/devel/datatype-character.html
Sorry for my long delay in reviewing this issue. You are correct this should be documented --- patch attached. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 4cc9e59270..07c3654b21 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1217,6 +1217,8 @@ SELECT '52093.89'::money::numeric::float8; <type>char(<replaceable>n</replaceable>)</type> are aliases for <type>character varying(<replaceable>n</replaceable>)</type> and <type>character(<replaceable>n</replaceable>)</type>, respectively. + The length specification must be greater than zero and cannot + exceed 10485760. <type>character</type> without length specifier is equivalent to <type>character(1)</type>. If <type>character varying</type> is used without length specifier, the type accepts strings of any size. The