aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-07-06 14:21:16 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-07-06 14:21:16 -0400
commitf7f70d5e22aa2330b8cc31dfc8732cd26ef0bbdd (patch)
tree05bc454bf489f4d289a2f156b43a70b364be806f /src/backend/access/gist
parentbae9e8a58bf642aa383f5dc01b2c5947bae533dd (diff)
downloadpostgresql-f7f70d5e22aa2330b8cc31dfc8732cd26ef0bbdd.tar.gz
postgresql-f7f70d5e22aa2330b8cc31dfc8732cd26ef0bbdd.zip
Create composite array types for initdb-created relations.
When we invented arrays of composite types (commit bc8036fc6), we excluded system catalogs, basically just on the grounds of not wanting to bloat pg_type. However, it's definitely inconsistent that catalogs' composite types can't be put into arrays when others can. Another problem is that the exclusion is done by checking IsUnderPostmaster in heap_create_with_catalog, which means that (1) If a user tries to create a table in single-user mode, it doesn't get an array type. That's bad in itself, plus it breaks pg_upgrade. (2) If someone drops and recreates a system view or information_schema view (as we occasionally recommend doing), it will now have an array type where it did not before, making for still more inconsistency. So this is all pretty messy. Let's just get rid of the inconsistency and decree that system-created relations should have array types if similar user-created ones would, i.e. it only depends on the relkind. As of HEAD, that means that the initial contents of pg_type grow from 411 rows to 605, which is a lot of growth percentage-wise, but it's still quite a small catalog compared to others. Wenjing Zeng, reviewed by Shawn Wang, further hacking by me Discussion: https://postgr.es/m/761F1389-C6A8-4C15-80CE-950C961F5341@gmail.com
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions