Thread: 16 parameter
I am certain this question has been asked and answered, but I didn't find the FAQ and the search feature on the website is "under construction." I apologize in advance. I am writing my first program in pgsql. My environment is OpenACS 4.5 beta1. While writing this program I need to create a function (actually, what I really need is an Oracle procedure with named -- rather than positional -- parameters) that has one paramenter for each attribute in my table. The error message is that only 16 parameters are allowed. A little investigative work has uncovered that the 16 parameters is a compile time option, yet I want to be able to distribute my code latter without my end users having to recompile. I further checked the TODO list, there is nothing that mentions ANY improvements to the pgsql language, yet I would think that named parameters, default values and more parameters would be near the top of the list. I guess I am very surprised because pgpsql is extremely functional, yet there doesn't seem to be any effort to improve it. How are folks handling this situation? Are you using a non-standard data type to pgpsql is extremely functional, yet there doesn't seem to be any effort to improve it. How are folks handling this situation? Are you using a non-standard data type to pass some kind of array or list to your pgsql function to get around the 16 parameter limit? Why not up the default for the distribution? Does performance suffer? Is anyone developing any serious applications with pgsql, or even porting over some Oracle apps? Is anyone improving this language to make it more developer friendly? I apologize that I could not take the time to properly orient myself to your list before posting. Feel free to orient me by fire if these comments are in the wrong spot. Thanks in advance, Andrew Lahser andrew@apl-software.com
----- Original Message ----- From: "andrew lahser" <andrew@apl-software.com> > > I further checked the TODO list, there is nothing that mentions ANY improvements to > the pgsql language, yet I would think that named parameters, default values and > more parameters would be near the top of the list. I guess I am very surprised because > pgpsql is extremely functional, yet there doesn't seem to be any effort to improve it. > it would be nice if some day the following are present too: - ability to group functions in packages (and define constants on package level) - numeric error codes (as opposed to string messages) for raised exceptions (not sure if this is pl/pgsql or Postgres limitation) Marin ---- "...what you brought from your past, is of no use in your present. When you must choose a new path, do not bring old experiences with you. Those who strike out afresh, but who attempt to retain a little of the old life, end up torn apart by their own memories. "
andrew lahser wrote: > I am certain this question has been asked and answered, but I > didn't find the FAQ and the search feature on the website is > "under construction." I apologize in advance. I would personally like to up the limit, and perhaps remove any limit to the number of arguments you can use for a function. However, we are a volunteer group so we need people to implement these changes. OpenACS seems to be one of the few apps that uses lots of parameters because of the way the thing is set up. The bottom line is that we don't get this request too often, and using one param per column isn't done too much, at least that I have heard. I am not saying it is wrong, but that we don't get much request for it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026