-
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: pg_attribute does not report stored columns on indexes #88107
Comments
I'm hitting a different error when I try this:
|
Sorry I am using a simplified version of Here's the problem query (replace the 3 occurrences of WITH obj AS (
SELECT c.oid, c.relchecks, c.relkind, c.relhasindex, c.relhasrules,
c.relhastriggers, c.relrowsecurity, c.relforcerowsecurity,
false AS relhasoids, c.relispartition, c.reltablespace,
CASE
WHEN c.reloftype = 0 THEN ''
ELSE c.reloftype::pg_catalog.regtype::pg_catalog.text END AS reloftype,
c.relpersistence, c.relreplident, am.amname
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)
LEFT JOIN pg_catalog.pg_am am ON (c.relam = am.oid)
WHERE c.oid = XXXXXXXX), cols AS (
SELECT a.attname,
pg_catalog.format_type(a.atttypid, a.atttypmod) AS typname,
CASE WHEN a.attnum <= (
SELECT i.indnkeyatts
FROM pg_catalog.pg_index i
WHERE i.indexrelid = XXXXXXXX) THEN 'yes' ELSE 'no' END AS is_key,
pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE) AS indexdef
FROM pg_catalog.pg_attribute a
WHERE a.attrelid = XXXXXX AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum)
SELECT attname AS "Column",
typname AS "Type",
is_key AS "Key?",
indexdef AS "Definition"
FROM cols |
Another thing I noticed while investigating this is that PG supports |
The problem here is with the
Also, @knz : what is the purpose of the |
I was mechanically translating what psql does. I'm not sure. I'll look at what the purpose was in psql. |
88061: clisqlshell: new infrastructure for describe commands r=rafiss,ZhouXing19 a=knz Fixes #95320. Epic: CRDB-23454 The SQL shell (`cockroach sql`, `demo`) now supports the client-side commands `\l`, `\dn`, `\d`, `\di`, `\dm`, `\ds`, `\dt`, `\dv`, `\dC`, `\dT`, `\dd`, `\dg`, `\du`, `\df` and `\dd` in a way similar to `psql`, including the modifier flags `S` and `+`, for convenience for users migrating from PostgreSQL. A notable difference is that when a pattern argument is specified, it should use the SQL "LIKE" syntax (with `%` representing the wildcard character) instead of PostgreSQL's glob-like syntax (with `*` representing wildcards). Issues discovered: - [x] join bug: #88096 - [x] semi-join exec error #91012 - [x] `pg_table_is_visible` should return true when given a valid index OID and the index is valid. #88097 - [x] missing pkey column in pg_index: #88106 - [x] missing stored columns in pg_index: #88107 - [x] pg_statistic_ext has problems #88108 - [x] missing view def on materialized views #88109 - [x] missing schema comments: #88098 - [x] missing pronamespace for functions #94952 - [x] broken pg_function_is_visible for UDFs #94953 - [x] generated columns #92545 - [x] indnullsnotdistinct #92583 - [x] missing prokind #95288 - [x] missing function comments in obj_description #95292 - [x] planning regression #95633 96397: builtins: mark some pg_.* builtins as strict r=DrewKimball a=mgartner Builtins defined using the UDF `Body` field will be wrapped in a `CASE` expression if they are strict, i.e., `CalledOnNullInput=false`. When the builtin is inlined, the `CASE` expression prevents decorrelation, leaving a slow apply-join in the query plan. This caused a significant regression of some ORM introspection queries. Some of these builtins have filters that cause the SQL body to return no rows if any of the arguments is NULL. In this case, the builtin will have the same behavior whether or not it is defined as being strict. We can safely optimize these builtins by setting `CalledOnNullInput=true`. The following conditions are sufficient to prove that `CalledOnNullInput` can be set for a builtin function with a SQL body: 1. The WHERE clause of the SQL query *null-rejects* every argument of the builtin. Operators like `=` and `<` *null-reject* their operands because they filter rows for which an operand is NULL. 2. The arguments are not used elsewhere in the query. This is not strictly necessary, but simplifies the proof because it ensures NULL arguments will not cause the builtin to error. Examples of SQL statements that would allow `CalledOnNullInput` to be set: ``` SELECT * FROM tab WHERE $1=1 AND $2='two'; SELECT * FROM tab WHERE $1 > 0; ``` Fixes #96218 Fixes #95569 Epic: None Release note: None 97585: cli: don't scope TLS client certs to a specific tenant by default r=stevendanna a=knz Epic: CRDB-23559 Fixes: #97584 This commit changes the default for `--tenant-scope` from "only the system tenant" to "cert valid for all tenants". Note that the scoping is generally useful for security, and it is used in CockroachCloud. However, CockroachCloud does not use our CLI code to generate certs and sets its cert tenant scopes on its own. Given that our CLI code is provided for convenience and developer productivity, and we don't expect certs generated here to be used in multi-tenant deployments where tenants are adversarial to each other, defaulting to certs that are valid on every tenant is a good choice. Release note: None Co-authored-by: Raphael 'kena' Poss <knz@thaumogen.net> Co-authored-by: Marcus Gartner <marcus@cockroachlabs.com>
Needed for #88061
Describe the problem
CockroachDB does not include stored columns in
pg_attribute
To Reproduce
Initialize with:
Then run
\d myidx
usingpsql
, on both PostgreSQL and CockroachDb.In pg, the (correct) output is:
In CockroachDB:
Notice how
y
is not listed.Jira issue: CRDB-19691
Epic: CRDB-23454
The text was updated successfully, but these errors were encountered: