Re: CALL versus procedures with output-only arguments
От | Tom Lane |
---|---|
Тема | Re: CALL versus procedures with output-only arguments |
Дата | |
Msg-id | 101881.1622757002@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CALL versus procedures with output-only arguments (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 03.06.21 22:21, Tom Lane wrote: >> An example is that (AFAICT) the spec allows having both >> create procedure divide(x int, y int, OUT q int) ... >> create procedure divide(x int, y int, OUT q int, OUT r int) ... >> which I want to reject because they have the same input parameters. > (I'm by no means suggesting this, but I could imagine a catalog > representation that allows this but still checks that you can't have > multiple candidates that differ only by the type of an OUT parameters. > Say with some kind of bitmap or boolean array that indicates where the > OUT parameters are. Then you can only have one candidate with a given > number of arguments, but the above could be allowed. Again, I'm not > suggesting this, but it's a possibility in theory.) We could certainly do something like that in a green field. But one of the reasons I'm unhappy about the current design is that I'm convinced that altering the definition of pg_proc.proargtypes will break client-side code that's looking at the catalogs. I don't think we get to monkey with such fundamental bits of the catalog data without a really good reason. Allowing different OUT parameters for the same IN parameters doesn't seem to me to qualify, given that there are other reasons why that's dubious. regards, tom lane
В списке pgsql-hackers по дате отправления: