Re: pg_upgrade: convert on read is dead end

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: pg_upgrade: convert on read is dead end
Дата
Msg-id 48F3515A.3030601@sun.com
обсуждение исходный текст
Ответ на Re: pg_upgrade: convert on read is dead end  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: pg_upgrade: convert on read is dead end  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows