"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > It's used in an example in 34.4.2 without a lot of definition. From > experimenting a bit, it appears that when referencing a composite data > value, any function which can take as its only parameter an instance > of that composite type can be used as though it were a field name. > This includes user functions written in any language, as well as > built-in aggregates (and presumably any other functions which accept a > composite type as the only parameter). Is that correct?
It goes the other way too: a column name can be used as though it were a function. You might want to look at the comments for and in ParseFuncOrColumn in backend/parser/parse_func.c. > Any > restrictions or exceptions? (I assume that they are only allowed to > retrieve values -- it doesn't seem like it would make sense to SET a > value into such a "computed field".) Right, this is only in places where a function call would be sensible. > It's clearly not particular to SQL functions, so it deserves mention > outside of the context you referenced. Chapter 4 does seem like a > good place. Under Column References or Function Calls (or both)? Not sure. I don't want to repeat a long spiel in both places ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs