Re: pg_upgrade: convert on read is dead end

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade: convert on read is dead end
Date: 2008-10-13 13:47:06
Message-ID: 48F3515A.3030601@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> Heikki Linnakangas napsal(a):
>>> Besides, the "read all formats" approach wouldn't really avoid it
>>> either. If you passed a toasted datum to a function, when the
>>> function needs to detoast it, detoast_datum still wouldn't know
>>> whether the datum is in old or new format. You'd still need to
>>> detoast all values in the tuple somewhere before they could be passed
>>> around.
>>
>> If you look into pg_upgrade prototype patch I added page version
>> information into HeapTupleData structure. It keeps information about
>> format. All chunked data are stored on a pages with same page
>> versions. I think these two things are enough to have all necessary
>> information.
>
> Functions are passed just a Datum, not HeapTupleData.
>

But executor works with HeapTupleData structure and it should convert it to the
new format before it passes it to function. My idea is to convert tuple in
ExecTupleStore or invent new node special for tuple conversion.

I expect that function cannot get toast pointer. It can get only detoasted
attributes. Correct me if I'm wrong.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-13 13:56:55 Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows
Previous Message Zdenek Kotala 2008-10-13 13:39:58 Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size