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

2013/2/26 Stephen Frost <sfrost(at)snowman(dot)net>:
> * 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.

this is not hard task, hard task is correct identification related function

see FuncnameGetCandidates() function

I am sure, so we don't would to duplicate this function on client side.

probably we can simplify searching to search only exact same signature
- but still there are problem with type synonyms. And solving this
code on client side means code duplication.

I prefer some smart searching function on server side - it can be
useful for other app too - pgAdmin, plpgsql debugger, ... And in psql
we can do switch - for older versions use current code, and for newer
"smart" server side function.

???

Regards

Pavel

>
> 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