On Thu, Jul 30, 2015 at 12:41 AM, Joe Conway <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/29/2015 07:58 PM, Tom Lane wrote:
> > We can definitely do
> >
> > SELECT x::any_single_unreserved_word(some_expression) FROM ...
> >
> > because that's actually not something the grammar needs to
> > distinguish from type-with-a-typmod; we can deal with the special
> > case in LookupTypeName. It's just a matter of picking a word
> > people like.
>
> What about just TYPE then?
>
> SELECT x::TYPE(some_expression) FROM ...
> SELECT CAST (x AS TYPE(some_expression)) FROM ...
>
>
The use case for dynamic column casting escapes me, so I don't feel
comfortable offering anything there. That discomfort will stop me for about
a paragraph.
As for record set casting, what about leveraging usage of the LIKE keyword
from derivative table creation, in some or all of these permutations:
a) SELECT * FROM recordset_returning_function() as t(LIKE
my_table_name);
b) SELECT * FROM recordset_returning_function() as t(LIKE
'my_table_name'::regclass);
c) SELECT * FROM recordset_returning_function() as t(LIKE
pg_typeof(p_some_anyelement_var));
Stepping into my discomfort zone, would the logical extension of allowing
the "b" case, where oids stand in for the type they reference, lead to:
SELECT CAST(x AS 'some_expression'::regclass) FROM ...
