From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Heap page diagnostic/test functions (WIP) |
Date: | 2007-03-06 14:44:48 |
Message-ID: | 87abyqbfdr.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> I'll return the infomasks directly, for you to manipulate.
>
> Not happy with that, but open to suggestions.
Well the alternative would be a long list of boolean columns which would make
the output kind of long.
Perhaps a function pg_decode_infomask(varbit) which returns a ROW of booleans
with appropriate names would be a good compromise. If you want it you could
use it in your query.
Or perhaps you could include a ROW of booleans in your output already,
something like:
postgres=# insert into tuple_info values (b'000', ROW(false,false,false));
INSERT 0 1
postgres=# select * from tuple_info;
infomask_bits | infomask_flags
---------------+----------------
000 | (f,f,f)
(1 row)
postgres=# select (infomask_flags).* from tuple_info;
flag_a | flag_b | flag_c
--------+--------+--------
f | f | f
(1 row)
That might be kind of tricky to cons up though. I had to create a table to do
it here.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-06 15:02:34 | Re: Aggressive freezing in lazy-vacuum |
Previous Message | Simon Riggs | 2007-03-06 14:15:28 | Re: Heap page diagnostic/test functions (WIP) |