Re: Allow to specify #columns in heap/index_form_tuple - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow to specify #columns in heap/index_form_tuple
Date
Msg-id 15195.1490988897@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow to specify #columns in heap/index_form_tuple  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... I also think we're setting up a situation where tools
>> like amcheck and pg_filedump are going to be unable to cope, because
>> figuring out what a particular tuple contains is going to require context
>> they haven't got.  It just seems way too dangerous.

> Why wouldn't they have the context?

Up to now, we have always had the property that you could decode an index
tuple given only the tuple and its relation's tupdesc (and likewise for
heap tuples).  This patch breaks that: now you need to know where in the
index the tuple came from.  That's a property that I think we will regret
losing.  No doubt we can make it work for some value of "work", but
there's going to be broken tools, and other opportunity costs down the
road.

> There is a free bit within IndexTupleData.t_info that could indicate
> that this is what happened.

Yeah, I was just looking at that, but it's the only bit we've got left.
Don't think we can use it both to deal with Anastasia's patch and your
suffix truncation idea.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: postgres_fdw IMPORT SCHEMA and partitioned tables
Next
From: Robert Haas
Date:
Subject: Re: [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint