Re: domain constraints and UNKNOWN params - Mailing list pgsql-patches

From Tom Lane
Subject Re: domain constraints and UNKNOWN params
Date
Msg-id 914.1137040276@sss.pgh.pa.us
Whole thread Raw
In response to domain constraints and UNKNOWN params  (Neil Conway <neilc@samurai.com>)
Responses Re: domain constraints and UNKNOWN params  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> I've also attached a patch that should fix the issue -- coerce_type()
> neglected to apply coerce_to_domain() to the type inferred for an
> UNKNOWN Param.

This is a good catch, but the patch's added check on targetTyptype is a
waste of code and cycles.  coerce_to_domain is perfectly capable of
doing nothing when nothing is called for.  (The reason the other paths
in the routine make such checks is that they can do so more or less for
free, thereby saving one catalog lookup in coerce_to_domain.  If it's
going to cost a catalog lookup anyway to find out if the type is a
domain, you might as well let coerce_to_domain do it.)

IOW, all you need to add is a coerce_to_domain call.  Compare a somewhat
related recent patch here:
http://archives.postgresql.org/pgsql-committers/2006-01/msg00125.php

> Barring any objections, I intend to apply the patch to
> HEAD and release branches as far back as the problem exists (likely 8.0
> and 8.1, and possibly 7.4 -- I haven't checked yet).

I think it's probably in 7.4 too.

I wonder whether there is any reasonably simple way to audit the whole
backend for missing domain processing...

            regards, tom lane

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: domain constraints and UNKNOWN params
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: Free WAL caches on switching segments