support specifying varchar lengths

[neverchanje]

Is your feature request related to a problem? Please describe.

We don't have to actually limit the max length for varchars. The idea is to omit the length parameter while accepting it at the frontend, so that we won't encounter errors when ecosystems tools try to create tables in the traditional PG way.

For example, database migration tools typically create temporary tables in databases to track execution histories.
Here's a table created by Liquibase:

CREATE TABLE databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INTEGER NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10))

Describe the solution you'd like

Accept the max length parameter, but omit it and return a notice clarifying that the length constraint won't be actually applied to the column.

Describe alternatives you've considered

We can provide a session-level configuration to enable/disable the compatibility.

Additional context

No response

[fuyufjh]

Ignoring varchar length sounds acceptable to me, but ignoring NOT NULL might be too dangerous. 🤔

[neverchanje]

I agree I am considering it after a second thought. Hoping that Github can allow tagging issues with "paused" label. 😢

[xxchan]

• varchar: fix(parser): reject varchar(n)'s (n) #4167
• not null: feat: not null constraint #8133

[xiangjinwu]

Ignoring varchar length sounds acceptable to me, but ignoring NOT NULL might be too dangerous. 🤔

When the length is 255 or 65535, it is likely the user did not think about it and just had to put in a placeholder value. Other length limits may be intentional.