Yea sure... I will look into the COLUM_TYPE issue and write a test
case for column names. On that note, when I ran the test suit all the
jdbc2 test would run fine, however, most of the others failed due to
"to many connections". I of course tried to up my max connections
beyond 20, but looks like will need to up shared memory maximums.
(which might be interesting given I am on os X. Just never done that
since switching). So before I go about figuring all that out, are
failures expected? and if not, any thoughts on the number of
connections I should configure for?
Jeff
On Jan 31, 2007, at 4:20 PM, Kris Jurka wrote:
>
>
> On Wed, 31 Jan 2007, Jeffrey Cox wrote:
>
>> I been working with metadata on stored procedures and discovered
>> that I can't get parameter names via getProcedureColumns. So i
>> checked out the source and took a look at the method. Seems that
>> for column names, a $ is appended to the arg type count. I guess I
>> don't know if there is a reason that the actual parameter names
>> are not used, or its just low on the TODO list. I went ahead and
>> updated the method return column names as stored in procargnames
>> of pg_catalog.pg_proc. I have attached a patch.
>
> It just hasn't been updated in a while.
>
>> I honestly don't know if this is the correct mechanism to handle
>> this (I poped into #postgres and was told to attach a patch to an
>> email to this list), so just point me in the right direction if
>> need be (either on how to submit the patch, or why making this
>> change is stupid).
>>
>
> This is exactly the place to send it. Any chance we can also
> convince you to add a test case and fix COLUMN_TYPE for out
> parameters?
>
> Kris Jurka