wieck@debis.com (Jan Wieck) writes:
> The rare cases, where someone really needs larger tuples and
> not beeing able to use the proposed LONG data type can be
> tackled by increasing BLKSIZE for this specific installation.
This would be a more convincing argument if we supported BLCKSZ
greater than 32K, but we don't.
I think we've speculated about having a compilation flag that gets
thrown to change page offsets from shorts to longs, thereby allowing
larger page sizes. But as Bruce was just pointing out, all of the
code depends in a fundamental way on the assumption that writing a
page is an atomic action. The larger the page size, the more likely
that you'll see broken tables caused by partial page writes. So
allowing BLCKSZ large enough to accomodate any tuple wouldn't be a
very good answer.
I think the proposed LONG type is a hack, and I'd rather see us solve
the problem correctly. ISTM that allowing a tuple to be divided into
"primary" and "continuation" tuples, all stored in the same relation
file, would be a much more general answer and not significantly harder
to implement than a LONG datatype as Jan is describing it.
regards, tom lane
