To: Michael Glaesmann <grzm@myrealbox.com>
Cc: pgsql-novice@postgresql.org
Subject: Re: Functional index problems. (Was: Many joins: monthly summaries
	S-L--O--W)
In-reply-to: <704FD876-04F0-11D8-81AE-0005029FC1A7@myrealbox.com> 
References: <704FD876-04F0-11D8-81AE-0005029FC1A7@myrealbox.com>
Comments: In-reply-to Michael Glaesmann <grzm@myrealbox.com>
	message dated "Thu, 23 Oct 2003 09:32:53 +0900"
Date: Wed, 22 Oct 2003 22:53:58 -0400
Message-ID: <25982.1066877638@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Glaesmann <grzm@myrealbox.com> writes:
> My final thought would be to continue using "functional index", noting
> that operators are a special class of function. Out of the above
> description of "value expression", I believe only functions and
> operators are allowed as expressions in the CREATE INDEX syntax,
> correct? (Besides referring to a column.)

Actually, you can use any scalar-valued expression that does not contain
a sub-SELECT or aggregate function.  (Aggregates would be meaningless
--- what are you aggregating over?  The prohibition of sub-SELECTs is
partly because we don't do planning for index expressions, which could
be fixed if anyone were sufficiently motivated, and partly because it
seems quite unlikely that the result of a SELECT could reasonably be
considered immutable.  We do *not* want to get into updating indexes for
reasons other than updates of the indexed row.)

I see your point that "functional index" is still a valid description,
but I'm inclined to bow to Peter's position that it has another meaning
that could distract people.  Presently I'm going to go with "expression
index" unless someone can provide a better choice.

			regards, tom lane