On 2016-09-12 14:05:33 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2016-09-12 13:48:05 -0400, Tom Lane wrote: > >> Andres Freund <and...@anarazel.de> writes: > >>> I kind of like ROWS FROM (... AS VALUE), that seems to confer the > >>> meaning quite well. As VALUE isn't a reserved keyword, that'd afaik only > >>> really work inside ROWS FROM() where AS is required. > > >> Hm, wouldn't ... AS RECORD convey the meaning better? > > > I was kind of envisioning AS VALUE to work for composite types without > > removing their original type (possibly even for TYPEFUNC_SCALAR > > ones). > > Maybe. A problem with any of these proposals though is that there's no > place to put a column alias. Yeah, you can stick it on outside the ROWS > FROM, but it seems a bit non-orthogonal to have to do it that way when > you can do it inside the ROWS FROM when adding a coldeflist.
I don't necessarily see that as a problem. The coldeflists inside ROWS FROM() already don't allow assigning aliases for !record/composite types, and they require specifying types. > >> (Although once you look at it that way, it's just a cast spelled in > >> an idiosyncratic fashion.) > > > Well, not quite, by virtue of keeping the original type around. After a > > record cast you likely couldn't directly access the columns anymore, > > even if it were a known composite type, right? > > Same is true for any of these syntax proposals, no? So far as the rest of > the query is concerned, the function output is going to be an anonymous > record type. Not for composite types, no. As implemented ROWS FROM (.. AS()) does: CREATE OR REPLACE FUNCTION get_pg_class() RETURNS SETOF pg_class LANGUAGE sql AS $$SELECT * FROM pg_class;$$; SELECT DISTINCT pg_typeof(f) FROM ROWS FROM (get_pg_class() AS ()) f; ┌───────────┐ │ pg_typeof │ ├───────────┤ │ pg_class │ └───────────┘ (1 row) SELECT (f).relname FROM ROWS FROM (get_pg_class() AS ()) f LIMIT 1; ┌────────────────┐ │ relname │ ├────────────────┤ │ pg_toast_77994 │ └────────────────┘ (1 row) which seems sensible to me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
