On Tue, Mar 25, 2008 at 2:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Brendan Jurd" <direvus(at)gmail(dot)com> writes:
> > This makes me wonder whether print.c could offer something a bit more
> > helpful to callers wishing to DIY a table; we could have a
> > table-building struct with methods like addHeader and addCell.
> > What do you think? Overkill, or worthy pursuit?
> Once you have two occurrences of a pattern, it's reasonable to assume
> there will be more later. +1 for building a little bit of infrastructure.
I've written a patch which implements the same \du behaviour as my
previous patch, but using the new printTable API I submitted in .
If the printTable API patch is rejected or substantially changed, we
will need to revisit this patch.
The new patch constructs a table manually, in the same manner as
describeOneTableDetails, so that we get the same outputs as the
original patch but without any of the localisation issues identified
by Tom and Alvaro.
I have attached a patch against my printTable code, containing only
the changes I made to describeRoles() (du-attributes_1.diff.bz2), and
a combined patch against HEAD containing the full printTable API
changes as well as the changes to describeRoles()
No memory problems detected by valgrind, and all regression tests
passed on x86_64 gentoo.
I've added this item to the May CommitFest wiki page.
In response to
pgsql-hackers by date
|Next:||From: James Mansion||Date: 2008-04-13 08:23:01|
|Subject: Re: Cached Query Plans|
|Previous:||From: Marc Cousin||Date: 2008-04-13 08:02:13|
|Subject: Re: Cached Query Plans (was: global prepared statements)|
pgsql-patches by date
|Next:||From: Andrew Chernow||Date: 2008-04-13 15:50:47|
|Subject: Re: libpq patch for pqtypes hook api and PGresult creation|
|Previous:||From: Tom Lane||Date: 2008-04-13 05:01:19|
|Subject: Re: [PATCH] sh: Add support Renesas SuperH |