sql: INET columns are not formatted during pretty-printing

[nvanbenschoten]

The following is the result of an EXPLAIN statement. It demonstrates that INET values are not properly formatted when pretty printing.

root@:26257/inettest> explain select * from users where addr = '2001:db8::68/0':::INET;
+------+-------+--------------------------------------------------------------------------+
| Tree | Field |                               Description                                |
+------+-------+--------------------------------------------------------------------------+
| scan |       |                                                                          |
|      | table | users@users_addr_idx                                                     |
|      | spans | /"\x01\x00                                                               |
|      |       | \x01\r\xb8\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00h"-/"\x01\x00      |
|      |       | \x01\r\xb8\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00h"/PrefixEnd       |
+------+-------+--------------------------------------------------------------------------+
(3 rows)

[nvanbenschoten]

@jordanlewis this might be a good starter project for a new engineer joining the SQL team.

[rohany]

@nvanbenschoten I found the root of the issue, but is unclear how to fix the problem in a backwards compatible way. In EncodeTableKey in src/github.com/cockroachdb/cockroach/pkg/sql/sqlbase/column_type_encoding.go, IPAddr values are encoded as byte streams, but they are given bytes tag, rather than an IPAddr tag for decoding. This results in the value not being decoded as an IPAddr when it is pretty printed. Fixing this requires changing the encoding the IPAddr objects which would differ with encodings that exist right now.

[nvanbenschoten]

So this is only an issue with IPAddr datums that are encoded in keys, not values, right? Do we have similar issues with other datum types? My understanding of this area of code is pretty out-of-date. Perhaps @solongordon has more information on whether this is acceptable behavior, and if not, what we should do about it.

[nvanbenschoten]

I'm not sure when this was addressed, but it seems to be fixed now:

demo@127.0.0.1:26257/movr> create table t (addr inet primary key);
CREATE TABLE

Time: 2ms total (execution 2ms / network 0ms)

demo@127.0.0.1:26257/movr> explain select * from t where addr = '2001:db8::68/0':::INET;
                        info
----------------------------------------------------
  distribution: local
  vectorized: true

  • scan
    missing stats
    table: t@primary
    spans: [/'2001:db8::68/0' - /'2001:db8::68/0']
(7 rows)

Time: 2ms total (execution 2ms / network 0ms)