Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> No, it's a really horrid idea. Nullable attributes complicate the C
>> code, and what in the world are we buying with it anyway? Just decide
>> what the field should contain and put it in there.
> The problem what we try to solve
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable?
Hmm, It seems to me as a good idea.
No, it's a really hor
Zdenek Kotala wrote:
> Tom Lane napsal(a):
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> >> Heikki Linnakangas napsal(a):
> >>> Perhaps we should just add the new attid attribute to the toast table,
> >>> but mark it as nullable?
> >
> >> Hmm, It seems to me as a good idea.
> >
> > No, it's a
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable?
Hmm, It seems to me as a good idea.
No, it's a really horrid idea. Nullable attributes complicate the
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas napsal(a):
>> Perhaps we should just add the new attid attribute to the toast table,
>> but mark it as nullable?
> Hmm, It seems to me as a good idea.
No, it's a really horrid idea. Nullable attributes complicate the C
code, and wha
Heikki Linnakangas napsal(a):
It the new attribute is added to the end, the old tuples will be
compatible as is. If there's no null bitmap (or it's shorter than
expectd), attributes missing from a tuple are implicitly NULL. That's
how we support ALTER TABLE ADD COLUMN without rewriting all the
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable? We wouldn't need to fill it in in the
8.3->8.4 conversion but new tuples would include it.
>
In the future release that we actually need it, we'll
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The question is if we should do toast modification now to avoid
potential future problems or if we will solve it when any on-disk
format change requires it?
Perhaps we should just add the new attid attribute to the toast table,
but mark it a
Zdenek Kotala wrote:
The question is if we should do toast modification now to avoid
potential future problems or if we will solve it when any on-disk format
change requires it?
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable? We wouldn't need to
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
2) data type is unknown
Unfortunately, in low function is no clue what data type is really
stored in a chunks.
Do we need to know? We haven't changed the on-disk format of any data
types between 8.3 and 8.4, have we?
Yeah, there is no cha
Zdenek Kotala wrote:
2) data type is unknown
Unfortunately, in low function is no clue what data type is really
stored in a chunks.
Do we need to know? We haven't changed the on-disk format of any data
types between 8.3 and 8.4, have we?
The other idea that was suggested earlier is to reto
We are now in discussion about toast table upgrading. I try to collect ideas and
figure out how it should work and where are problems.
Overview:
-
A few weeks ago we made a decision to use convert on read. We already made a
decision how to solve problem with overflow data after conversi
12 matches
Mail list logo
