2013/2/26 Stephen Frost <sfrost@snowman.net>:
> * Tom Lane (tgl@sss.pgh.pa.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
