Hiroshi Inoue [EMAIL PROTECTED] writes:
To make it usable for inherited tables requires truly
horrendous kluges (as you well know).
Logical/physical attribute numbers solves it naturally.
Maybe. At this point that's a theory without experimental evidence
to back it up ;-). I'm still
Hiroshi Inoue wrote :
[ ... ]
Column order isn't essential in rdbms.
Nitpicking
A relation (a table) is a subset of the Cartesain cross-product of the
definition domains of the attributes (columns). Cartesian product being
a commutative operation, "order of columns" does not really exists.
Tom Lane wrote:
ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
That's a fragile and unclean implementation IMHO --- see past
Hannu Krosing wrote:
Tom Lane wrote:
ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
That's a fragile and unclean
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
That's a fragile and
i Inoue" [EMAIL PROTECTED]
Cc: "Hannu Krosing" [EMAIL PROTECTED]; "Michael Richards"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, December 17, 2000 8:05 PM
Subject: Re: [HACKERS] Tuple data
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
ALTER ADD COLUMN do
"Michael Richards" [EMAIL PROTECTED] writes:
What are the cases where the current implementation does not handle it
properly?
Inheritance.
CREATE TABLE parent (a, b, c);
CREATE TABLE child (z) INHERITS (parent);
ALTER TABLE parent ADD COLUMN (d);
With the current implementation you now
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
This is what I assumed the problem to be but I wasn't sure if there would be
more to it or not.
My question now is: Should the order in which columns are physically stored
matter?
Since the details of where to find the columns in the tuple data are stored
in pg_attribute, I'd think this is a
Hi.
I've still got something I can't seem to get. In my test cases with simple
tables the first uint16 of tuple data after the header contained the length
of the tuple. In this case I can't seem to figure out what the value F24D
stands for when I'd expect it's length to be 0800.
The first tuple
"Michael Richards" [EMAIL PROTECTED] writes:
I've still got something I can't seem to get. In my test cases with simple
tables the first uint16 of tuple data after the header contained the length
of the tuple.
That's not right --- AFAIR there is no length in the tuple data. You
must use the
Michael Richards wrote:
Hi.
I've still got something I can't seem to get. In my test cases with simple
tables the first uint16 of tuple data after the header contained the length
of the tuple. In this case I can't seem to figure out what the value F24D
stands for when I'd expect it's
Michael Richards wrote:
That's not right --- AFAIR there is no length in the tuple data. You
must use the length from the 'page item' pointer that points to this
tuple if you want to know the total tuple length.
Oops, I meant attribute length...
If you were testing with tables
I'm not sure, but you may see some part of the NULL bitmap.
IIRC it started at a quite illogical place, is suspect it was at byte 31
but
it still reserved 4bytes for each 32 fields after byte 32
Sometimes the t_hoff value in the tuple header is 32 which seems to indicate
no NULL bitmap. This
pg_attribute tells you the types and ordering of the attributes
(columns) of a table. Then see pg_type for the size and alignment
of each type.
regards, tom lane
"Michael Richards" [EMAIL PROTECTED] writes:
Sometimes the t_hoff value in the tuple header is 32 which seems to indicate
no NULL bitmap.
There's no null bitmap unless the HASNULLS infomask bit is set.
This really makes me wonder what happens when you ALTER
TABLE ADD COLUMN on a table since
16 matches
Mail list logo
