On 3/16/18 11:40, Tom Lane wrote: > Michael Paquier <mich...@paquier.xyz> writes: >> On Fri, Mar 16, 2018 at 11:35:13AM +0530, Prabhat Sahu wrote: >>> postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID >>> LANGUAGE SQL >>> AS $$ >>> select 10; >>> $$; > >> Problem reproducible here, and the bug has been introduced by fd1a421f. >> It seems to me that the function should not be authorized to be created >> to begin with, as it returns an integer in its last query, where I think >> that check_sql_fn_retval is doing it wrong when called in >> inline_function() as we know that it handles a function, and not a >> procedure thanks to the first sanity checks at the top of the function. > > Hm. Actually, I think this is my fault. It is true that previous PG > versions would have rejected this function definition, but my intention > while revising Peter's prokind patch was that we'd start allowing a > VOID-returning SQL function to contain anything, and just ignore whatever > the last statement within it might be. The documentation doesn't say > much about VOID-returning SQL functions, but I certainly don't see > anything saying that they can't end with a SELECT, so arguably the old > behavior is a POLA violation. In any case, this is the behavior we > need for VOID-returning procedures, and there seems little reason not > to make functions act similarly. > > So apparently I missed something with that. Will look more closely.
This was listed as an open item, but it was already fixed by 877cdf11eaa9cabcb9b1e3c1bef0760fe08efdc3, so I'll remove it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services