2013/2/26 Stephen Frost <sfr...@snowman.net>: > * Tom Lane (t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
