| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: tablecmds.c/MergeAttributes() cleanup |
| Date: | 2024-01-12 10:32:26 |
| Message-ID: | 202401121032.nch3eqk73bow@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024-Jan-11, Alvaro Herrera wrote:
> If you look closely at InsertPgAttributeTuples and accompanying code, it
> all looks a bit archaic. They seem to be treating TupleDesc as a
> glorified array of Form_pg_attribute elements in a convenient packaging.
> It's probably cleaner to change these APIs so that they deal with a
> Form_pg_attribute array, and not TupleDesc anymore. But we can hack on
> that some other day.
In addition, it also occurs to me now that maybe it would make sense to
change the TupleDesc implementation to use a List of Form_pg_attribute
instead of an array, and do away with ->natts. This would let us change
all "for ( ... natts ...)" loops into foreach_ptr() loops ... there are
only five hundred of them or so --rolls eyes--.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"El sudor es la mejor cura para un pensamiento enfermo" (Bardia)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Banck | 2024-01-12 10:54:29 | Re: plpgsql memory leaks |
| Previous Message | Hayato Kuroda (Fujitsu) | 2024-01-12 10:31:01 | RE: speed up a logical replica setup |