On 18 April 2016 at 02:22, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <david.row...@2ndquadrant.com> writes: >> Note that I've done nothing for the weird schema prefixing problem I >> mentioned. I think I'd need input on the best way to solve this. If >> it's actually a problem. > > It sure looks like a problem to me. Maybe it's only cosmetic, but > it's going to cause confusion and bug reports. EXPLAIN output for > parallel queries is going to be confusing enough anyway; we need > to avoid having artifacts like this.
I'd like to admit that I'm a bit confused as to why generate_function_name(), when it already knows the funcid, bothers to call func_get_detail(), which performs a search for the function based on the name and argument types, to find the function, most likely with the same funcid as the one which it already knew. Could you explain why this has to happen? I also tried patching with the attached and running the regression tests to see what breaks... nothing did. So it seems that, at least in the tests that that code path is never hit. With that in mind, perhaps the fix for the namespace problem is just to special case the combine Aggrefs in get_agg_expr() and have it just lookup the pg_proc entry for the aggred->aggfnoid, and use that proname. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
generate_function_name_experiment.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
