Re: getProcedureColumns
От | Jeffrey Cox |
---|---|
Тема | Re: getProcedureColumns |
Дата | |
Msg-id | 53951298-D245-4EB2-9C3E-EA05A48C77BA@gmail.com обсуждение исходный текст |
Ответ на | Re: getProcedureColumns (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: getProcedureColumns
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: