On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >>> Incidently the fix looks quite simple. See patch attached. >> >> ISTM this patch effectively proposes to make procedures have their own >> namespace yet still live in pg_proc. That is the worst of all possible >> worlds IMO. Somewhere early in this patch series, I complained that >> procedures should be in a different namespace and therefore not be kept >> in pg_proc but in some new catalog. That argument was rejected on the >> grounds that SQL requires them to be in the same namespace, which I >> wasn't particularly sold on, but that's where we are. If they are in >> the same namespace, though, we have to live with the consequences of >> that, including ambiguity. Otherwise there will soon be questions >> like "well, why can't I create both function foo(int) and procedure >> foo(int), seeing that there's no question which of them a particular >> statement intends to call?". > > That question did cross my mind and I think that's a valid question.
I agree, but I'm not sure it settles the issue. If you hand somebody a plate and a slice of pizza and say "eat this", you expect them to understand that they should try to eat the pizza, not the plate. You expect this because virtually all human beings over the age of two understand that pizza is eatable and plates are not. It is similar reasonable to expect that when the database is asked to call one of two things, one of which can be called and the other of which cannot, it might decide to try calling the one that can be called rather than the one that can't. I think we need procedures and functions to live in the same namespace because otherwise DROP ROUTINE foo(int) could find two things equally worthy of being dropped, and we don't want that to happen (leaving aside the question of whether DROP ROUTINE is a good idea in the first place). That does not mean -- to me anyway -- that we've got to make CALL latch onto a function when a procedure is available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
