Re: [BUGS] Breakage with VACUUM ANALYSE + partitions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Date
Msg-id 16963.1462388297@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> * debugger ability to print variables symbolically

> I might be misunderstanding what you're getting at here, but if you want
> to be able to use #define'd values using their name, you can get that by
> compiling with -g3.  With -g3 and gdb, you can do things like:

> (gdb) p tblinfo[i].dobj.dump & ~(DUMP_COMPONENT_COMMENT |
> DUMP_COMPONENT_SECLABEL | DUMP_COMPONENT_USERMAP | DUMP_COMPONENT_ACL)

> where all the DUMP_COMPONENT items are #define's.

Yes, but if you just do "p tblinfo[i].dobj.dump", you're only going to get
a number, right?  The value-added for an enum type is that the debugger
knows which symbol to substitute for a numeric value when printing.  But
that stops working if what's in the variable is some OR of the values the
debugger knows about.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Proposal: Remove regress-python3-mangle.mk
Next
From: Stephen Frost
Date:
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions