Three types of functions, ala function redux.

From: mlw <markw(at)mohawksoft(dot)com>
To: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Three types of functions, ala function redux.
Date: 2000-12-19 18:41:10
Message-ID: 3A3FABC6.5B608AEB@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Given this basic SQL statement:

select * from table where col = function() ;

There are three basic types of SQL behaviors that should be able to be
performed.

(1) "function()" returns a single value. Postgres should be able to
understand how to optimize this to be: "select * from table where col =
value" where value is the datum returned by function.

(2) "function()" returns a number of values that are independent of the
query. Postgres should be able to optimize this to be: "select * from
table where col in (val1, val2, val3, ..valn)." I guess Postgres can
loop until done, using the isDone flag?

(3) "function()" returns a value based on the query. (This seems to be
how it currently functions.) where "select * from table where col =
function()" will end up doing a full table scan.

(1) and (2) are related, and could probably be implemented using the
same code.
(3) Seems to be how Postgres is currently optimized.

It seems like Tom Lane laid the foundation for this behavior in 7.1
newC. (Does it now work this way?)

Does anyone see a problem with this thinking, and does it make sense to
attempt this for 7.2? I am looking into the function manager stuff to
see what would be involved.

--
http://www.mohawksoft.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joseph 2000-12-19 18:56:33 Help me for "DBI->connect failed: Sorry, too many clients already."
Previous Message Christopher Masto 2000-12-19 18:33:58 Re: Who is a maintainer of GiST code ?