Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 9B3462E002F
	for <pgsql-sql-postgresql.org@postgresql.org>;
	Fri, 15 Feb 2008 19:03:08 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 28813-04 for <pgsql-sql-postgresql.org@postgresql.org>;
	Fri, 15 Feb 2008 19:03:05 -0400 (AST)
Received: from mail.mailpen.net (mail.mailpen.net [209.90.228.14])
	by postgresql.org (Postfix) with ESMTP id 009132E002E
	for <pgsql-sql@postgresql.org>; Fri, 15 Feb 2008 19:03:04 -0400 (AST)
Received: from [192.168.42.79] (207.155.204.150.ptr.us.xo.net
	[207.155.204.150])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.mailpen.net (Postfix) with ESMTP id 1ABC525ED6C
	for <pgsql-sql@postgresql.org>; Fri, 15 Feb 2008 15:03:03 -0800 (PST)
Message-ID: <47B61A26.4060806@ultimeth.com>
Date: Fri, 15 Feb 2008 15:03:02 -0800
From: "Dean Gibson (DB Administrator)" <postgresql@ultimeth.com>
Organization: UltiMeth Systems
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: pgsql-sql <pgsql-sql@postgresql.org>
Subject: Re: FUNCTIONs and CASTs
References: <47B4C9E4.8090002@ultimeth.com> <20670.1203031191@sss.pgh.pa.us>
	<47B4EF3E.4090608@ultimeth.com> <47B55DA1.1060706@archonet.com>
	<47B5D790.4090509@ultimeth.com> <655.1203114745@sss.pgh.pa.us>
In-Reply-To: <655.1203114745@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------010008070805090605080101"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200802/135
X-Sequence-Number: 30226

This is a multi-part message in MIME format.
--------------010008070805090605080101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2008-02-15 14:32, Tom Lane wrote:
> "Dean Gibson (DB Administrator)" <postgresql@ultimeth.com> writes:
>   
>> Again, you are not understanding my point.  My point was that specifying 
>> tablename.columnname%TYPE notation doesn't help with the performance 
>> problem;  I have to explicitly cast the parameter in the body of the 
>> function.
>>     
>
> The reason for the lack of communication is that no one else believes
> that premise.  Casting a value to the same type it already has is
> demonstrably a no-op.
>   
Casing a TEXT item to a CHAR( 9 ) item isn't a no-op.  I've seen this 
before in "EXPLAIN ..." output, where a search on an indexed column will 
be sequential because the planner treats the search value as TEXT rather 
than CHAR( 9 ).

Are you saying that no one believes there is a performance difference?  
Amazing ...

Tom, I've privately eMailed you access instructions to one of my DB 
servers, so you can see for yourself.

-- 
Mail to my list address MUST be sent via the mailing list.
All other mail to my list address will bounce.


--------------010008070805090605080101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 2008-02-15 14:32, Tom Lane wrote:
<blockquote cite="mid:655.1203114745@sss.pgh.pa.us" type="cite">
  <pre wrap="">"Dean Gibson (DB Administrator)" <a class="moz-txt-link-rfc2396E" href="mailto:postgresql@ultimeth.com">&lt;postgresql@ultimeth.com&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Again, you are not understanding my point.  My point was that specifying 
tablename.columnname%TYPE notation doesn't help with the performance 
problem;  I have to explicitly cast the parameter in the body of the 
function.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The reason for the lack of communication is that no one else believes
that premise.  Casting a value to the same type it already has is
demonstrably a no-op.
  </pre>
</blockquote>
Casing a TEXT item to a CHAR( 9 ) item isn't a no-op.&nbsp; I've seen this
before in "EXPLAIN ..." output, where a search on an indexed column
will be sequential because the planner treats the search value as TEXT
rather than CHAR( 9 ).<br>
<br>
Are you saying that no one believes there is a performance difference?&nbsp;
Amazing ...<br>
<br>
Tom, I've privately eMailed you access instructions to one of my DB
servers, so you can see for yourself.<br>
<br>
<pre class="moz-signature" cols="72">-- 
Mail to my list address MUST be sent via the mailing list.
All other mail to my list address will bounce.</pre>
</body>
</html>

--------------010008070805090605080101--