| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: InsertPgAttributeTuple() and attcacheoff |
| Date: | 2018-08-14 15:50:12 |
| Message-ID: | 681.1534261812@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> It seems to me that it would make sense if InsertPgAttributeTuple() were
> to set attcacheoff to -1 instead of taking it from the caller.
Looked this over, no objections.
I wonder whether we should set that field to -1 when we *read*
pg_attribute rows from disk, and be less fussed about what gets written
out. The only real advantage is that this'd protect us from foolish
manual changes to pg_attribute.attcacheoff entries, but that doesn't
seem negligible.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-08-14 15:51:10 | Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. |
| Previous Message | Alexander Korotkov | 2018-08-14 15:38:56 | Re: [HACKERS] Bug in to_timestamp(). |