Re: FUNCTIONs and CASTs

On 2008-02-15 15:03, Dean Gibson (DB Administrator) wrote:
> On 2008-02-15 14:32, Tom Lane wrote:
>
> 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.
>

OK, it must have been late at 2am when I last ran the tests, as it now
seems to work. By "work", I mean that the casting in the function body
is (in the particular case I was having an issue with) apparently
unnecessary if the types are proper (which includes the
table.column%TYPE notation).

I'm happy to find that out, since now I can use the table.column%TYPE
notation to advantage.

What helped confuse me is that the following function apparently DOES
need an internal cast:

CREATE OR REPLACE FUNCTION zzz( aaa CHAR(1) ) RETURNS CHAR(1) LANGUAGE
SQL AS 'SELECT $1';

SELECT zzz( 'abc' );

returns "abc", not "a". Apparently declarations of CHAR(n) are treated
as BPCHAR in function prototypes???

-- Dean

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