On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote: > On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: >> A thought I had as I fell asleep last night is to include the derivate >> flags in a separate output column altogether. So >> heap_tuple_infomask_flags() could be made to return two columns, one >> with the straight one-flag-per-bit, and another one with the compound >> flags. > > So, in most cases, the compound column will be empty, but in some > cases like HEAP_XMIN_FROZEN, HEAP_XMAX_SHR_LOCK, etc. the flag will be > displayed. I like this idea though it will be a bit of noise in some > cases but it is neat. Another benefit is that one doesn't need to > invoke this function twice to see the compound flags.
Hmmm. Doesn't it become less user-friendly to invoke the function then? You would need to pass it down to the FROM clause after fetching the raw page and then parsing its tuple items to have t_infomask and t_infomask2 passed down as arguments to the new function. The one-column version has the advantage to be more consistent with tuple_data_split() after getting all the values parsed by heap_page_items(). >> That way we always have the raw ones available, and we avoid any >> confusion about strange cases such as LOCK_UPGRADED and IS_LOCKED_ONLY. > > Yeah, but I am not sure if we want to do display LOCK_UPGRADED stuff > in the compound column as that is not directly comparable to other > flags we want to display there like HEAP_XMIN_FROZEN, > HEAP_XMAX_SHR_LOCK. Yep, I agree that this one ought to not be considered as a proper combination. The other three ones are fine though. -- Michael
signature.asc
Description: PGP signature
