On Mon, May 23, 2011 at 12:42 PM, Noah Misch <noah@leadboat.com> wrote:
> I'd like to revive the discussion that arose during the last CommitFest over
> the proper design for identifying no-op length coercions like varchar(4) ->
> varchar(8). Here is the root of the original debate:
>
> http://archives.postgresql.org/message-id/20110109220353.GD5777@tornado.leadboat.com
>
> There were two proposals on the table:
>
> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean" function
> to the pg_cast; call it in find_coercion_pathway()
> 2. Attach a "f(FuncExpr) RETURNS Expr" (actually internal/internal) function
> to the pg_proc; call it in simplify_function()
>
> I tried and failed to write a summary of the respective arguments that could
> legitimately substitute for (re-)reading the original thread, so I haven't
> included one. I myself find the advantages of #2 mildly more compelling.
The main reason I preferred #1 is that it would only get invoked in
the case of casts, whereas #2 would get invoked for all function
calls. For us to pay that overhead, there has to be some use case,
and I didn't find the examples that were offered very compelling. How
many CPU cycles are we willing to spend trying to simplify x + 0 to
just x, or x * 0 to just 0? I might be missing something here, but
those strikes me as textbook examples of cases where it's not worth
slowing down the whole system to fix a query that the user could have
easily written in some less-pathological way to begin with.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
