Re: [PATCHES] Show INHERIT in \du

From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bernd Helmle" <mailings(at)oopsware(dot)de>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] Show INHERIT in \du
Date: 2008-03-24 16:30:48
Message-ID: 37ed240d0803240930y6fcad470i784ec8f3bc05f968@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On 21/03/2008, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Brendan Jurd" <direvus(at)gmail(dot)com> writes:
> > We can't just build the output table by hand like
> > describeOneTableDetails does? Admittedly it's kludgy, but it's not an
> > unprecedented kludge.
>
>
> Oh, I had forgotten the existence of that entry point in print.c. Yeah,
> it might be workable --- want to have a go at it?
>

I've had a chance to look at this now, and although it certainly does
seem workable, there's a lot of duplication of code that I feel uneasy
about. describeOneTableDetails essentially already duplicates the
table buildling code in printQuery, so I would be creating a third
copy of the same logic.

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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-03-24 16:34:57 Re: New email list for emergency communications
Previous Message Tom Lane 2008-03-24 16:24:40 Re: Bug in libpq causes local clients to hang

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-03-24 16:41:08 Re: [PATCHES] Show INHERIT in \du
Previous Message Brendan Jurd 2008-03-24 10:49:04 Re: [HACKERS] Function structure in formatting.c