Re: pl/pgsql Composite Parameter Question
От | Bruce Momjian |
---|---|
Тема | Re: pl/pgsql Composite Parameter Question |
Дата | |
Msg-id | 200203080124.g281OaE29943@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pl/pgsql Composite Parameter Question (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pl/pgsql Composite Parameter Question
|
Список | pgsql-general |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> Looks like a bug to me :-(. Unfortunately, there's no time to do > >> anything about it for 7.2. In the meantime, the 16-parameter limit > >> is by no means graven in stone; perhaps you could cope for awhile > >> by recompiling with a larger FUNC_MAX_ARGS. > > > Tom, can you summarize the issue here? > > The issue for our TODO is that plpgsql doesn't work very well with > composite (rowtype) parameters. I am confused how this relates to the 16-parameter limit mentioned in the message. Is it limited to 16 columns of a composite type? > > Our 16-param limit is for both > > old and new-style functions? Did we agree to increase this, perhaps to > > 24 or 32. Did we decide? > > I don't recall any consensus in favor of changing the default value of > FUNC_MAX_ARGS. It's already twice what it used to be. I do remember a discussion. Certain heavy users are using object-oriented programming routines and 16 is too small. I know of at least two big users, Ben Adida (OpenACS), and Josh Berkus, who would like the limit increased. They can increase it themselves, but because they distribute source to others, all installs then have to have the modification. I think they would be happy with 24. -- 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, Pennsylvania 19026
В списке pgsql-general по дате отправления: