Date: Thu, 23 Oct 2003 09:32:53 +0900
Subject: Re: Functional index problems. (Was: Many joins: monthly summaries
	S-L--O--W)
Content-Type: multipart/alternative; boundary=Apple-Mail-4-515143512
Mime-Version: 1.0 (Apple Message framework v552)
From: Michael Glaesmann <grzm@myrealbox.com>
To: pgsql-novice@postgresql.org
In-Reply-To: <18109.1066850278@sss.pgh.pa.us>
Message-Id: <704FD876-04F0-11D8-81AE-0005029FC1A7@myrealbox.com>

--Apple-Mail-4-515143512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed

On Thursday, Oct 23, 2003, at 04:17 Asia/Tokyo, Tom Lane wrote:
> I'm not particularly happy with the phrase "expressional index", and
> would like to think of something else to use before the 7.4 docs go
> final.  Any ideas?

Though it might be nice to be creative and name it something like=20
"Bill", for a defined language like SQL I think it's best to work=20
within the framework already used to describe the language. Looking in=20
the PostgreSQL docs (which I'm sure you've done), I find this=20
definition of "value expression"

A value expression is one of the following:
- A constant or literal value; see Section 1.1.2 .
- A column reference.
- A positional parameter reference, in the body of a function=20
declaration.
- An operator invocation.
- A function call.
- An aggregate expression.
- A type cast.
- A scalar subquery.
- Another value expression in parentheses, useful to group=20
subexpressions and override precedence.

Preceding this is a paragraph mentioning that value expressions are=20
also called "scalar expressions" or just "expressions". I was surprised=20
to find column references are included in this list, but thinking about=20
it, a column has a scalar value, which is what any function or operator=20
returns as well. According to the above description of "value=20
expression", a normal column index is just a special case of the more=20
general "expression" index.

(Actually, I'm a bit confused with the definition of value expression.=20
Does column reference here mean value in the same row (and same table)?=20
That's the only way I can see getting a scalar value. If it means=20
reference in the constraint meaning, it's a set of allowed values,=20
rather than a specific one, which definitely wouldn't work for an=20
index. Perhaps the use of the word "reference" here is inappropriate,=20
though I haven't looked through the rest of the documentation to see=20
how the term "column reference" is used. My bad, I know. I'll=20
definitely accept criticism for not doing my homework thoroughly.)

To me, an operator is just a special class of function that doesn't use=20
the more general func(arg [, arg]) construction. 2 + 2 could just as=20
easily be add(2,2) =97 and maybe it is already defined this way as well.=20
I haven't checked.

However, I can see that it might be useful to distinguish between=20
functions and column references. One term I thought about was "derived=20
index". Another was "evaluated index". But both of these terms seem to=20
introduce unnecessary language.

My final thought would be to continue using "functional index", noting=20
that operators are a special class of function. Out of the above=20
description of "value expression", I believe only functions and=20
operators are allowed as expressions in the CREATE INDEX syntax,=20
correct? (Besides referring to a column.)

What do you think?

Michael
--Apple-Mail-4-515143512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=WINDOWS-1252

On Thursday, Oct 23, 2003, at 04:17 Asia/Tokyo, Tom Lane wrote:

<excerpt>I'm not particularly happy with the phrase "expressional
index", and

would like to think of something else to use before the 7.4 docs go

final.  Any ideas?

</excerpt>

Though it might be nice to be creative and name it something like
"Bill", for a defined language like SQL I think it's best to work
within the framework already used to describe the language. Looking in
the PostgreSQL docs (which I'm sure you've done), I find this
definition of "value expression"


<fontfamily><param>Lucida Grande</param><bigger>A value expression is
one of the following:=20

- A constant or literal value; see
<color><param>0000,0000,6666</param>Section 1.1.2 </color>.

- A column reference.=20

- A positional parameter reference, in the body of a function
declaration.=20

- An operator invocation.=20

- A function call.=20

- An aggregate expression.=20

- A type cast.=20=20

- A scalar subquery.=20

- Another value expression in parentheses, useful to group
subexpressions and override precedence.=20


Preceding this is a paragraph mentioning that value expressions are
also called "scalar expressions" or just "expressions". I was
surprised to find column references are included in this list, but
thinking about it, a column has a scalar value, which is what any
function or operator returns as well. According to the above
description of "value expression", a normal column index is just a
special case of the more general "expression" index.


(Actually, I'm a bit confused with the definition of value expression.
Does column reference here mean value in the same row (and same
table)? That's the only way I can see getting a scalar value. If it
means reference in the constraint meaning, it's a set of allowed
values, rather than a specific one, which definitely wouldn't work for
an index. Perhaps the use of the word "reference" here is
inappropriate, though I haven't looked through the rest of the
documentation to see how the term "column reference" is used. My bad,
I know. I'll definitely accept criticism for not doing my homework
thoroughly.)


To me, an operator is just a special class of function that doesn't
use the more general func(arg [, arg]) construction. 2 + 2 could just
as easily be add(2,2) =97 and maybe it is already defined this way as
well. I haven't checked.


However, I can see that it might be useful to distinguish between
functions and column references. One term I thought about was "derived
index". Another was "evaluated index". But both of these terms seem to
introduce unnecessary language.


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.)


What do you think?


Michael</bigger></fontfamily>
--Apple-Mail-4-515143512--