From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | depesz(at)depesz(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: unhelpful error message |
Date: | 2009-06-18 18:12:58 |
Message-ID: | 12929.1245348778@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-18 18:32:22 | Re: BUG #4860: Indexes gone after restore |
Previous Message | Obe, Regina | 2009-06-18 18:07:19 | Re: BUG #4860: Indexes gone after restore |