Re: [bug] Table not have typarray when created by single user mode

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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;
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.


regards, tom lane

Attachment Content-Type Size
remove-pg_type-entries-for-seqs-and-toast-tables.patch text/x-diff 15.2 KB

In response to


Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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