Re: [HACKERS] LONG

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [HACKERS] LONG
Дата
Msg-id Pine.GSO.4.02A.9912111712290.5375-100000@Krabba.DoCS.UU.SE
обсуждение исходный текст
Ответ на Re: [HACKERS] LONG  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] LONG  (wieck@debis.com (Jan Wieck))
Re: [HACKERS] LONG  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Sat, 11 Dec 1999, Bruce Momjian wrote:

> In fact, you could get fancy and allow an update of a non-pg_long using
> column to not change pg_long at all.  Just keep the same value in the
> column.  If the transaction fails or succeeds, the pg_long is the same
> for that tuple.  Of course, because an update is a delete and then an
> insert, that may be hard to do.  For very long fields, it would be a win
> for UPDATE.  You certainly couldn't do that with chained tuples.

While this is great and all, what will happen when long tuples finally get
done? Will you remove this, or keep it, or just make LONG and TEXT
equivalent? I fear that elaborate structures will be put in place here
that might perhaps only be of use for one release cycle.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] LONG
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Last thoughts about LONG