On Mon, May 23, 2011 at 1:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, May 23, 2011 at 12:42 PM, Noah Misch <n...@leadboat.com> wrote: >>> 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. > > Well, as I pointed out in > http://archives.postgresql.org/pgsql-hackers/2011-01/msg02570.php > a hook function attached to pg_proc entries would cost nothing > measurable when not used. You could possibly make the same claim > for attaching the hook to pg_cast entries, if you cause the optimization > to occur during initial cast lookup rather than expression > simplification. But I remain of the opinion that that's the wrong place > to put it.
So you said here: http://archives.postgresql.org/pgsql-hackers/2011-01/msg02575.php http://archives.postgresql.org/pgsql-hackers/2011-01/msg02585.php The trouble is, I still can't see why type OIDs and typemods should be handled differently. Taking your example again: CREATE TABLE base (f1 varchar(4)); CREATE VIEW vv AS SELECT f1::varchar(8) FROM base; ALTER TABLE base ALTER COLUMN f1 TYPE varchar(16); Your claim on the thread is that we want to someday allow this case. But what if the last statement were instead: ALTER TABLE base ALTER COLUMN f1 TYPE integer; Should it also be our goal to handle that case? If not, why are they different? -- 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
