> Hannu Krosing <hannu@2ndQuadrant.com> writes:
> > If there is plan invalidation then you just change called1() to return
> > one more field and that's it - no juggling with C) and D) and generally
> > less things that can go wrong.
>
> That is a pure flight of fancy.
Nope, this is description of real situation when you have to maintain
lots and lots of functions.
> Adjusting a function's API generally
> requires source-code changes on the caller side too.
Adding a column to table does not (even generally) require changing all
queries accessing that table, why should adding a column to functions
return type do ?
> There might be
> a few limited cases where you can avoid that, but that doesn't leave
> you with much of an argument that this is a critical bug fix. It's
> a corner case and little more.
It is a corner case if you don't have a dynamic system, evolving over
time, which relies heavily on functions .
It is a complete non-issue if you don't use functions at all.
> FWIW, given that there will probably always be corner cases. I can see
> the attraction in Simon's suggestion of providing a way to manually
> issue a system-wide forced plan flush.
That was also what I suggested as one blanket way of solving the bigger
issue you brought up, that of not knowing where to stop tracking
dependencies for plan invalidation.
My thinking was, that this trades one-time inefficiency (replanning all
stored plans) against more general but spread in time inefficiency of
current patch (sending registration messages around for each function
OID you depend on at each time you plan ).
------------
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment