On 2008-02-15 15:03, Dean Gibson (DB Administrator) wrote: <blockquote cite="mid:47B61A26.4060806@ultimeth.com"
type="cite"></blockquote>On 2008-02-15 14:32, Tom Lane wrote:<br /><br /> Casing a TEXT item to a CHAR( 9 ) item isn't
ano-op. I've seen this before in "EXPLAIN ..." output, where a search on an indexed column will be sequential because
theplanner treats the search value as TEXT rather than CHAR( 9 ).<br /><br /> Are you saying that no one believes there
isa performance difference? Amazing ...<br /><br /><strike>Tom, I've privately eMailed you access instructions to one
ofmy DB servers, so you can see for yourself.</strike><br /><br /><br /> OK, it must have been late at 2am when I last
ranthe tests, as it now seems to work. By "work", I mean that the casting in the function body is (in the particular
caseI was having an issue with) apparently unnecessary if the types are proper (which includes the table.column%TYPE
notation).<br/><br /> I'm happy to find that out, since now I can use the table.column%TYPE notation to advantage.<br
/><br/> What helped confuse me is that the following function apparently DOES need an internal cast:<br /><br /> CREATE
ORREPLACE FUNCTION zzz( aaa CHAR(1) ) RETURNS CHAR(1) LANGUAGE SQL AS 'SELECT $1';<br /><br /> SELECT zzz( 'abc' );<br
/><br/> returns "abc", not "a". Apparently declarations of CHAR(n) are treated as BPCHAR in function prototypes???<br
/><br/> -- Dean<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>
