Message-Id: <4CCADE440200002500036FB2@gw.wicourts.gov>
Date: Fri, 29 Oct 2010 14:46:28 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>,<pgsql-bugs@postgresql.org>,
	"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Jon Nelson" <jnelson+pgsql@jamponi.net>
Subject: Re: [PERFORM] typoed column name, but postgres didn't
	 grump
References: <AANLkTimYMA8D2h4-jHK5vD032jWwig1iJmW6uF-3i=Bx@mail.gmail.com>
	<4480.1288374498@sss.pgh.pa.us>
	<4CCACE6E0200002500036F95@gw.wicourts.gov>
	<6240.1288379246@sss.pgh.pa.us>
	<AANLkTim35FrP1EyZRmnotKSw=2rq8JNVutkitn9PXwFp@mail.gmail.com>
In-Reply-To: <AANLkTim35FrP1EyZRmnotKSw=2rq8JNVutkitn9PXwFp@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Robert Haas <robertmhaas@gmail.com> wrote:
 
>> 2. The notation t(x) will be taken to mean x::t if there's no
>> function t() taking x's type, but there is a cast from x's type
>> to t.
 
>> I think if I had to pick a proposal, I'd say we should disable #2
>> for the specific case of casting a composite type to something
>> else.
 
> Well, then let's do that.  It's not the exact fix I'd pick, but
> it's clearly better than nothing, so I'm willing to sign on to it
> as a compromise position.
 
It seems a bad idea to have so many different syntaxes for identical
CAST semantics, but there they are, and it's bad to break things. 
One of the reasons #2 seems like the place to fix it is that it's
pretty flaky anyway -- "it will be taken to mean x unless there no y
but there is a z" is pretty fragile to start with.  Adding one more
condition to the places it kicks in doesn't seem as good to me as
dropping it entirely, but then I don't have any code which depends
on type(value) as a cast syntax -- those who do will likely feel
differently.
 
So, I'd rather scrap #2 entirely; but if that really would break
much working code, +1 for ignoring it when it would cast a composite
to something else.
 
-Kevin