increasing FUNC_MAX_ARGS insufficient? - Mailing list pgsql-general

From Gregory Seidman
Subject increasing FUNC_MAX_ARGS insufficient?
Date
Msg-id 20020808072428.GA12500@cs.brown.edu
Whole thread Raw
Responses Re: increasing FUNC_MAX_ARGS insufficient?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Mario Weilguni
Date:
Subject: any way to check if a transaction is active?
Next
From: Tom Lane
Date:
Subject: Re: increasing FUNC_MAX_ARGS insufficient?