From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | shawn wang <shawn(dot)wang(dot)pg(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, wenjing <wjzeng2012(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> |
Subject: | Re: [bug] Table not have typarray when created by single user mode |
Date: | 2020-07-06 20:22:39 |
Message-ID: | 1468768.1594066959@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
I wrote:
> However, if we're going to go this far, I think there's a good
> case to be made for going all the way and eliminating the policy
> of not making array types for system catalogs. That was never
> anything but a wart justified by space savings in pg_type, and
> this patch already kills most of the space savings. If we
> drop the system-state test in heap_create_with_catalog altogether,
> we end up with 601 initial pg_type entries. That still leaves
> the four bootstrap catalogs without array types, because they are
> not created by heap_create_with_catalog; but we can manually add
> those too for a total of 605 initial entries. (That brings initial
> pg_type to 14 pages as I show above; I think it was 13 with the
> original version of the patch.)
> In short, if we're gonna do this, I think we should do it like
> the attached. Or we could do nothing, but there is some appeal
> to removing this old inconsistency.
I pushed that, but while working on it I had a further thought:
why is it that we create composite types but not arrays over those
types for *any* relkinds? That is, we could create even more
consistency, as well as buying back some of the pg_type bloat added
here, by not creating pg_type entries at all for toast tables or
sequences. A little bit of hacking later, I have the attached.
One could argue it either way as to whether sequences should have
composite types. It's possible to demonstrate queries that will
fail without one:
regression=# create sequence seq1;
CREATE SEQUENCE
regression=# select s from seq1 s;
ERROR: relation "seq1" does not have a composite type
but it's pretty hard to believe anyone's using that in practice.
Also, we've talked more than once about changing the implementation
of sequences to not have a relation per sequence, in which case the
ability to do something like the above would go away anyway.
Comments?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
remove-pg_type-entries-for-seqs-and-toast-tables.patch | text/x-diff | 15.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Soumyadeep Chakraborty | 2020-07-06 22:45:23 | Re: posgres 12 bug (partitioned table) |
Previous Message | Tom Lane | 2020-07-06 13:48:49 | Re: BUG #16528: Analytical function with Over clause for ARRAY datatype is not working properly |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-07-06 20:33:51 | Re: Multi-byte character case-folding |
Previous Message | Ajay Patel | 2020-07-06 19:54:50 | Question: PostgreSQL on Amazon linux EC2 |