increasing FUNC_MAX_ARGS insufficient?

Поиск
Список
Период
Сортировка
От Gregory Seidman
Тема increasing FUNC_MAX_ARGS insufficient?
Дата
Msg-id 20020808072428.GA12500@cs.brown.edu
обсуждение исходный текст
Ответы Re: increasing FUNC_MAX_ARGS insufficient?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
I followed Neil Conway's helpful instructions on changing FUNC_MAX_ARGS:

1. change FUNC_MAX_ARGS in src/include/pg_config.h
2. make clean
3. recompile
4. reinstall
5. initdb

Having done so, I should now be able to create functions with up to 64
arguments. I created the following functions to test it:

create function sumit (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int,
int)returns int as ' 
        declare runsum int;
        begin
        runsum := $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8 + $9 + $10
                + $11 + $12 + $13 + $14 + $15 + $16 + $17 + $18 + $19 + $20;
        return runsum;
        end;
' language 'plpgsql';

create function sumit (int, int, int, int, int, int, int, int, int, int) returns int as '
        declare runsum int;
        begin
        runsum := $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8 + $9 + $10;
        return runsum;
        end;
' language 'plpgsql';

To save you counting, the first sumit takes 20 integers, which is more than
unmodified PostgreSQL can handle, and the second takes 10. There are several
strange things about them. First off, psql gives strange results with \df:

template1=> \df sumit

                                                                          List of functions 
 Result data type | Name  |
                                                                                      Argument data types

                                             

------------------+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 integer          | sumit | integer, integer, integer, integer, integer, integer, integer, integer, integer, integer,
-,-, -, -, -, -, ???, -, -, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???,
???,???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, -, -, ???, ???, oidvector, ???, ???, ???, ??? 
 integer          | sumit | integer, integer, integer, integer, integer, integer, integer, integer, integer, integer,
integer,integer, integer, integer, integer, integer, ???, -, -, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???,
???,???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???,
???,???, ???, ???, ???, ???, ???, ???, ???, ??? 
(2 rows)

Second, while the 10 argument form works perfectly, the 20 argument form
gives the following:

template1=> select sumit(1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0);
NOTICE:  plpgsql: ERROR during compile of sumit near line 0
ERROR:  cache lookup for argument type 100 failed

Any thoughts on this? I am sure I am using the modified PostgreSQL
installation for everything. This isn't an issue of incompatible binaries.

--Greg


В списке pgsql-general по дате отправления:

Предыдущее
От: Mario Weilguni
Дата:
Сообщение: any way to check if a transaction is active?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: increasing FUNC_MAX_ARGS insufficient?