Hannu Krosing wrote:
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
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 [ * ]
Tom,
Here's an attempt to do some major rethinking and solve all open issues
(and of course creating some new ones).
The idea is based on use of normal tables with a bytea column that
stores one LO-page per row (henceforth referred to as LO-page tables).
Several such tables can be used in
Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
the inv_api.c and will use that as the base for my implementation.
The inv_api large objects are deprecated. CLOBs and BLOBs should be based
on text and bytea,
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
the inv_api.c and will use that as the base for my implementation.
The inv_api large objects are deprecated. CLOBs and BLOBs should
Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
the inv_api.c and will use that as the base for my implementation.
The inv_api large objects are deprecated. CLOBs and BLOBs should be based
on text and
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide streaming media for thousands of users.
You can use the
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide streaming media for thousands of users.
--On Sonntag, November 28, 2004 14:55:29 +0100 Thomas Hallgren
[EMAIL PROTECTED] wrote:
From what I can see, the current JDBC driver uses the lo_xxx client
api's and they seem to map to the inv_xxx server api's.
Huh, does that mean the libpq's lo_*() API is deprecated, too? That would
be bad
The inv_api large objects are deprecated. CLOBs and BLOBs should be based
on text and bytea, respectively.
Until bytea is actually useful with large scale binaries I would
say that large objects are far from deprecated. You can't reasonably
store large binary date in bytea.
Large objects are
Thomas Hallgren wrote:
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide streaming media for
Joe Conway wrote:
Thomas Hallgren wrote:
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide
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 |
David Garamond [EMAIL PROTECTED] writes:
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 }
The semantics are
Thomas Hallgren [EMAIL PROTECTED] writes:
What is the quality of the large object solution today. Does it have
known flaws that nobody cares about since it's discontinued or is it
considered a maintained and worthy part of the overall solution?
More the former than the latter, I think, at
15 matches
Mail list logo
