Re: CALL versus procedures with output-only arguments

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: CALL versus procedures with output-only arguments
Дата
Msg-id f2274317-aa5f-70f1-075b-7a6223608359@enterprisedb.com
обсуждение исходный текст
Ответ на Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 04.06.21 23:07, Tom Lane wrote:
> I wrote:
>> It would likely not be very hard to fix pg_dump to include explicit
>> IN markers.  I don't think this results in a compatibility problem
>> for existing dumps, since they won't be taken from databases in
>> which there are procedures with OUT arguments.
> 
> Actually, all we have to do to fix pg_dump is to tweak ruleutils.c
> (although this has some effects on existing regression test outputs,
> of course).  So maybe it's not as bad as all that.
> 
> Here's a draft-quality patch to handle ALTER/DROP this way.  I think
> the code may be finished, but I've not looked at the docs at all.
> 
> 0001 is the same patch I posted earlier, 0002 is a delta to enable
> handling ALTER/DROP per spec.

I checked these patches.  They appear to match what was talked about.  I 
didn't find anything surprising.  I couldn't apply the 0002 after 
applying 0001 to today's master, so I wasn't able to do more exploratory 
testing.  What are these patches based on?  Are there are any more open 
issues to focus on?

One thing I was wondering is whether we should force CALL arguments in 
direct SQL to be null rather than allowing arbitrary expressions.  Since 
there is more elaborate code now to process the CALL arguments, maybe it 
would be easier than before to integrate that.



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: SQL-standard function body
Следующее
От: Peter Eisentraut
Дата:
Сообщение: automatically generating node support functions