Re: bugfix: --echo-hidden is not supported by \sf statements

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bugfix: --echo-hidden is not supported by \sf statements
Date: 2013-02-26 20:08:49
Message-ID: 20130226200849.GZ16142@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Dunno, I think that's going to result in a very large chunk of mostly
> duplicative code in psql. regprocedurein() is fairly short because it
> can rely on a ton of code from the parser, but psql won't have that
> luxury.

Parsing/tokenizing a CSV string inside parens doesn't strike me as all
that difficult, even when handling the space-delimininated varname from
the type.

The hard part would, I think, be the normalization of the
type names into what \df returns, but do we even want to try and tackle
that..?. How much do we care about supporting every textual
representation of the 'integer' type? That's not going to be an issue
for people doing tab-completion or using \df's output. We could also
have it fall-back to trying w/o any arguments for a unique function name
match if the initial attempt w/ the function arguments included doesn't
return any results.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-26 20:28:27 Re: PGXS contrib builds broken?
Previous Message Tom Lane 2013-02-26 19:59:48 Re: bugfix: --echo-hidden is not supported by \sf statements