-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: INT4 column type not reported as INT4 when inspecting column types (SHOW CREATE, errors etc) #25098
Labels
A-sql-semantics
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
O-community
Originated from the community
S-3-ux-surprise
Issue leaves users wondering whether CRDB is behaving properly. Likely to hurt reputation/adoption.
Comments
Reported by @borovan on Gitter. |
Oh, weird. It does do 32-bit int validation even though it claims to be root@:26257/> insert into foo.bar values (2147483647, 0, 0);
INSERT 1
Time: 2.085641ms
root@:26257/> insert into foo.bar values (2147483648, 0, 0);
pq: integer out of range for type INTEGER (column "x") |
The error is in the output of SHOW CREATE TABLE and the generation of the text of the error messages. Underneath in the table descriptor the type is different. |
knz
added
the
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
label
Apr 26, 2018
knz
added
the
S-3-ux-surprise
Issue leaves users wondering whether CRDB is behaving properly. Likely to hurt reputation/adoption.
label
Apr 26, 2018
knz
changed the title
sql: INT4 column type automatically converted to INTEGER on table creation
sql: INT4 column type not reported as INT4 when inspecting column types (SHOW CREATE, errors etc)
Apr 26, 2018
craig bot
pushed a commit
that referenced
this issue
Aug 23, 2018
28690: sql: fix the handling of integer types r=knz a=knz Addresses a large chunk of #26925. Fixes #25098. Informs #24686. Prior to this patch, CockroachDB maintained an unnecessary distinction between "INT" and "INTEGER", between "BIGINT" and "INT8", etc. This distinction is unnecessary but also costly, as we were paying the price of a "name" attribute in coltypes.TInt, with a string comparison and hash table lookup on every use of the type. What really matters is that the type shows up properly in introspection; this has already been ensured by various OID-to-pgcatalog mappings and the recently introduced `InformationSchemaTypeName()`. Any distinction beyond that is unnecessary and can be dropped from the implementation. Release note: None Co-authored-by: Raphael 'kena' Poss <knz@cockroachlabs.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-sql-semantics
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
O-community
Originated from the community
S-3-ux-surprise
Issue leaves users wondering whether CRDB is behaving properly. Likely to hurt reputation/adoption.
According to https://www.cockroachlabs.com/docs/stable/int.html#names-and-aliases, INT4 is treated as a 32-bit type that can't simply be aliased to a full 64-bit
INTEGER
. However, the actual code does convertINT4
columns toINTEGER
on both v1.1.4 and v2.0.1:Which is wrong -- the code or the docs?
The text was updated successfully, but these errors were encountered: