On Thu, Jul 30, 2015 at 12:41 AM, Joe Conway <mail@joeconway.com> 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 ...