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.
