2018-06-04 9:59 GMT+02:00 Vik Fearing <vik.fear...@2ndquadrant.com>: > On 04/06/18 09:37, Pavel Stehule wrote: > > > > > > 2018-06-04 9:24 GMT+02:00 Heikki Linnakangas <hlinn...@iki.fi > > <mailto:hlinn...@iki.fi>>: > > > > On 04/06/18 09:12, Pavel Stehule wrote: > > > > It requires introduction of new "safe" functions (& operators). > > Immutable > > functions are not enough safe. > > > > CREATE OR REPLACE FUNCTION public.fx() > > RETURNS integer > > LANGUAGE plpgsql > > IMMUTABLE > > AS $function$ > > BEGIN > > RETURN (SELECT count(*) FROM pg_class); > > END; > > $function$ > > > > postgres=# SELECT fx(); > > ┌─────┐ > > │ fx │ > > ╞═════╡ > > │ 343 │ > > └─────┘ > > (1 row) > > > > > > That function is incorrectly marked as IMMUTABLE. In that situation, > > it's enough that we throw a sane error like "ERROR: no snapshot > > available". > > > > Yes, it is incorrect mark. Unfortunately - this is often workaround for > > wrong estimations - so I afraid, in this case, your proposed fix breaks > > lot of applications. > > I would say such applications are already broken. >
I cannot to agree, not in this moment: 1. there is not any workaround, how to force subselect evaluation in planning time - what can be correct for once only evaluated queries. 2. what is not prohibited, is enabled. I agree so this trick is ugly - but I got it from Tom if I remember well maybe more than 10 years ago. Now is too late change it - I think - probably we find more strange features that we hold due compatibility. But this discussion is offtopic for this thread. I am thinking so lot of expressions can be significantly accelerated and I would to check it. Regards Pavel -- > Vik Fearing +33 6 46 75 15 36 > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support >
