Re: Implicit coercions need to be reined in

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implicit coercions need to be reined in
Date: 2002-04-11 16:30:01
Message-ID: 2044.1018542601@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> We have never been in complete agreement on the optimal behavior for
> type coersion, but it seems that most users are blissfully ignorant of
> the potential downsides of the current behavior. Another way to phrase
> that would be to say that it actually does the right thing in the vast
> majority of cases out in the field.

Could be; we probably see more complaints about the lack of any coercion
path for particular cases than about inappropriate implicit coercions.
But we do see a fair number of the latter. (And in the cases where I've
resisted adding more coercions, it was precisely because I thought it'd
be dangerous to allow them implicitly --- that concern goes away once
we can mark a coercion function as not implicitly invokable.)

> We'll probably both agree that it would be nice to avoid *hard coded*
> rules of any kind for this, but do you share my concern that moving this
> to a database table-driven set of rules will affect performance too
> much?

AFAICT the performance cost is negligible: find_coercion_function has to
look at the pg_proc row anyway. The relevant change looks like

PointerGetDatum(oid_array),
ObjectIdGetDatum(typnamespace));
! if (!HeapTupleIsValid(ftup))
! {
! ReleaseSysCache(targetType);
! return InvalidOid;
! }
! /* Make sure the function's result type is as expected, too */
! pform = (Form_pg_proc) GETSTRUCT(ftup);
! if (pform->prorettype != targetTypeId)
{
ReleaseSysCache(ftup);
- ReleaseSysCache(targetType);
- return InvalidOid;
}
! funcid = ftup->t_data->t_oid;
! ReleaseSysCache(ftup);
ReleaseSysCache(targetType);
return funcid;
}
--- 711,734 ----
Int16GetDatum(nargs),
PointerGetDatum(oid_array),
ObjectIdGetDatum(typnamespace));
! if (HeapTupleIsValid(ftup))
{
+ Form_pg_proc pform = (Form_pg_proc) GETSTRUCT(ftup);
+
+ /* Make sure the function's result type is as expected */
+ if (pform->prorettype == targetTypeId && !pform->proretset &&
+ !pform->proisagg)
+ {
+ /* If needed, make sure it can be invoked implicitly */
+ if (isExplicit || pform->proimplicit)
+ {
+ /* Okay to use it */
+ funcid = ftup->t_data->t_oid;
+ }
+ }
ReleaseSysCache(ftup);
}
!
ReleaseSysCache(targetType);
return funcid;
}

I do not see any reason not to install the mechanism; we can fine-tune
the actual pg_class.proimplicit settings as we get experience with them.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-04-11 16:31:22 Re: RFC: Restructuring pg_aggregate
Previous Message Gavin Sherry 2002-04-11 16:26:47 Re: help with bison