On 2008-02-15 14:32, Tom Lane wrote: <blockquote cite="mid:655.1203114745@sss.pgh.pa.us" type="cite"><pre
wrap="">"DeanGibson (DB Administrator)" <a class="moz-txt-link-rfc2396E"
href="mailto:postgresql@ultimeth.com"><postgresql@ultimeth.com></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. I've seen this before
in"EXPLAIN ..." output, where a search on an indexed column will be sequential because the planner treats the search
valueas TEXT rather than CHAR( 9 ).<br /><br /> Are you saying that no one believes there is a performance difference?
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>
