On Fri, 2010-12-31 at 11:09 -0500, Tom Lane wrote:
> Thor Michael =?ISO-8859-1?Q?St=F8re?= <thormichael@gmail.com> writes:
> > Right, it says it should "uniquely" identify the function within the
> > schema, which as far as I can tell means that for overloaded functions
> > it would have to list up the input argument types. (Or at least the
> > other only unique way to identify a function I can think of is the OID,
> > which I can't believe one would want there.)
>
> I'll bet a nickel that the expectation is for this to be pulled from
> information_schema.routines.specific_name, which is defined thusly in
> Postgres:
>
> CAST(p.proname || '_' || CAST(p.oid AS text) AS sql_identifier)
> ... FROM pg_proc p
>
> As best I can tell from the SQL spec, the <specific name> of a function
> is implementation-dependent, so this is a compliant way of doing it.
Aah, wasn't aware of that, that makes sense.
Also, I see SPECIFIC_NAME was added to JDBC 4, so I imagine that to
correctly add it one would override getProcedures and
getProcedureColumns in
org.postgresql.jdbc4.AbstractJdbc4DatabaseMetaData and have them return
the additional column(s). I took a look at the code and it seem straight
forward enough for getProcedures, but getProcedureColumns has six other
new columns as well and seems a bit hairier so I'm not sure if should
throw myself over adding this.
Thanks either way to everyone, I quite understand the state of things
now.
- thormick
