On Tue, Sep 03, 2024 at 10:19:33PM +0200, Matthias van de Meent wrote:
> On Fri, 30 Aug 2024, 23:06 Nathan Bossart, <nathandbossart@gmail.com> wrote:
>> Another related inconsistency I just noticed in pageinspect:
>>
>> postgres=# select t_data from heap_page_items(get_raw_page('s', 0));
>> t_data
>> --------------------------------------
>> \x0100000000000000000000000000000000
>> (1 row)
>>
>> postgres=# select tuple_data_split('s'::regclass, t_data, t_infomask, t_infomask2, t_bits) from
heap_page_items(get_raw_page('s',0));
>> ERROR: only heap AM is supported
>
> I don't think this is an inconsistency:
>
> heap_page_items works on a raw page-as-bytea (produced by
> get_raw_page) without knowing about or accessing the actual relation
> type of that page, so it doesn't have the context why it should error
> out if the page looks similar enough to a heap page. I could feed it
> an arbitrary bytea, and it should still work as long as that bytea
> looks similar enough to a heap page.
> tuple_data_split, however, uses the regclass to decode the contents of
> the tuple, and can thus determine with certainty based on that
> regclass that it was supplied incorrect (non-heapAM table's regclass)
> arguments. It therefore has enough context to bail out and stop trying
> to decode the page's tuple data.
My point is really that tuple_data_split() needlessly ERRORs for sequences.
Other heap functions work fine for sequences, and we know it uses the heap
table AM, so why should tuple_data_split() fail? I agree that the others
needn't enforce relkind checks and that they might succeed in some cases
where tuple_data_split() might not be appropriate.
--
nathan
