Re: Identifying no-op length coercions

On Mon, May 23, 2011 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, May 23, 2011 at 12:42 PM, Noah Misch <noah@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