| 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: | Whole Thread | Raw Message | 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) |