Re: Status of server side Large Object support?

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Thomas Hallgren <thhal(at)mailblocks(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, bryan(at)bulten(dot)ca
Subject: Re: Status of server side Large Object support?
Date: 2004-12-08 00:33:38
Message-ID: 1102466018.4020.11.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On E, 2004-11-29 at 02:22, David Garamond wrote:
> Joe Conway wrote:
> > Not if the column is storage type EXTERNAL. See a past discussion here:
> > http://archives.postgresql.org/pgsql-general/2003-07/msg01447.php
>
> what is the reasoning behind this syntax?
>
> ALTER TABLE [ ONLY ] table [ * ]
> ALTER [ COLUMN ] column SET STORAGE
> { PLAIN | EXTERNAL | EXTENDED | MAIN }
>
> I find it nonintuitive and hard to remember. Perhaps something like this
> is better (I know, it's probably too late):
>
> ALTER [ COLUMN ] column SET STORAGE { INLINE | EXTERNAL }
> ALTER [ COLUMN ] column SET COMPRESSION { YES | NO }

It wold also be beneficial if the threshold size of moving the column to
TOAST (either COMPRESS or EXTERNAL) could be set on a per-column basis

This is a design decision on the same lavel as the others

------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-12-08 01:10:42 regression script/makefile exit failure
Previous Message Nicolai Tufar 2004-12-07 23:38:56 Re: apparent problem on linux/s390