From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HEAD \df doesn't show functions with no arguments |
Date: | 2005-04-01 05:26:20 |
Message-ID: | 3264.1112333180@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> What makes you think you can't call 'em from SQL?
> Yes, I guess I mean does it make sense to call them from SQL? Their
> purpose is for internal use, no?
People have actually used them for purposes of cross-type conversion
where there's I/O compatibility but no built-in cast. For instance
you can't
regression=# select '(1,2)'::point::text;
ERROR: cannot cast type point to text
but you can
regression=# select textin(point_out('(1,2)'::point));
textin
--------
(1,2)
(1 row)
Before you look down your nose at that, consider it's *exactly* what
plpgsql does whenever it needs to do a type conversion.
I think this decision was taken many years ago when indeed you couldn't
use the things from SQL, but it's an obsolete point of view. It's not
like the functions are typically named in a way that conflicts with
other functions. If I do "\df int4in", what exactly do you think I'm
looking for, and why should psql not show it to me?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-04-01 05:29:57 | Re: [HACKERS] HEAD \df doesn't show functions with no arguments |
Previous Message | elein | 2005-04-01 05:19:35 | Re: HEAD \df doesn't show functions with no arguments |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-04-01 05:29:57 | Re: [HACKERS] HEAD \df doesn't show functions with no arguments |
Previous Message | elein | 2005-04-01 05:19:35 | Re: HEAD \df doesn't show functions with no arguments |