On Mon, May 23, 2011 at 12:42 PM, Noah Misch <n...@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.gd5...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
