Обсуждение: Question about casts

Just out of curiosity (and most likely, ignorance). Why can't I cast an 
array of strings into a string? I.e.
 thhal=# select ('{"a","b"}'::varchar[])::varchar; ERROR:  cannot cast type character varying[] to character varying

or a cstring into a varchar, i.e.
 thhal=# select array_out('{"a","b"}'::varchar[])::varchar; ERROR:  cannot cast type cstring to character varying

ISTM, the implementation of such casts should be fairly simple and 
straight forward and sometimes even useful. Every data type comes with 
string coercion routines anyway right?

Regards,
Thomas Hallgren

On Thu, May 18, 2006 at 05:41:14PM +0200, Thomas Hallgren wrote:
> Just out of curiosity (and most likely, ignorance). Why can't I cast an
> array of strings into a string? I.e.
>
>  thhal=# select ('{"a","b"}'::varchar[])::varchar;
>  ERROR:  cannot cast type character varying[] to character varying

Why would you need to? What would you expect to happen? Joined with a
seperator, no seperator, with parenthesis?

> or a cstring into a varchar, i.e.
>
>  thhal=# select array_out('{"a","b"}'::varchar[])::varchar;
>  ERROR:  cannot cast type cstring to character varying

varchar_in will do the conversion, why would want to make it a cast?
What's the benefit of a cast over a function call?

> ISTM, the implementation of such casts should be fairly simple and
> straight forward and sometimes even useful. Every data type comes with
> string coercion routines anyway right?

Every cast costs space and lookup time. Any user can add their own
casts if they want, but the system generally only includes the ones
useful to many people or those required for standards complience.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout wrote:
> On Thu, May 18, 2006 at 05:41:14PM +0200, Thomas Hallgren wrote:
>   
>> Just out of curiosity (and most likely, ignorance). Why can't I cast an 
>> array of strings into a string? I.e.
>>
>>  thhal=# select ('{"a","b"}'::varchar[])::varchar;
>>  ERROR:  cannot cast type character varying[] to character varying
>>     
>
> Why would you need to? What would you expect to happen? Joined with a
> seperator, no seperator, with parenthesis?
>
>   
Well, let's assume I use JDBC. I write code like:
 ResultSet rs = stmt.executeQuery("SELECT arrValue ..."); while(rs.next())     String v = rs.getString(1);

The tuples received by the result set contains String[]. If I let 
PL/Java convert it (I don't currently), it will be according to Java 
semantics. I'd like to convert it using PostgreSQL semantics instead. So 
I change my statement to:
 "SELECT array_out(arrValue) ..."

that works of course. What baffles me is that I cannot write
 "SELECT arrValue::varchar"


> What's the benefit of a cast over a function call?
>
>   
None whatsoever. But PostgreSQL enables a lot of casts for some reason 
or another right? Why not this one?

> Every cast costs space and lookup time. Any user can add their own
> casts if they want, but the system generally only includes the ones
> useful to many people or those required for standards complience.
>
>   
OK. I can live with that. I would have thought that casting into the 
string types was something that could be hardwired since the backing 
functions are mandatory.

Regards,
Thomas Hallgren

Thomas Hallgren <thomas@tada.se> writes:
> I would have thought that casting into the 
> string types was something that could be hardwired since the backing 
> functions are mandatory.

This has been proposed before, and seems reasonable to me (as long as
the casts are explicit-only), and I think it's listed in TODO; but
nobody's gotten around to it.
        regards, tom lane

Martijn van Oosterhout <kleptog@svana.org> writes:
> Every cast costs space and lookup time.

Actually, we could probably have a net time savings here if the text
cast cases were hard-wired into parse_coerce.c.  The reason is that
about 10% of the default entries in pg_cast are "retail" implementations
of text-to-or-from-foo casts, and we could get rid of all those entries,
not to mention the associated pg_proc entries and underlying code.
That would certainly cut search time in pg_cast enough to pay for a
couple of hard-wired "typoid == TEXTOID" checks.
        regards, tom lane