X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id C53869DCC1F for ; Sun, 5 Mar 2006 16:10:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 05005-02 for ; Sun, 5 Mar 2006 16:10:45 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from puntd5.cc.uga.edu (puntd5.cc.uga.edu [128.192.1.108]) by postgresql.org (Postfix) with ESMTP id 411239DCC71 for ; Sun, 5 Mar 2006 16:10:42 -0400 (AST) Received: from uga.edu (cantor.english.uga.edu [128.192.25.103]) by puntd5.cc.uga.edu (MOS 3.5.9-GR) with SMTP id CPV63837 (AUTH via LOGINBEFORESMTP); Sun, 5 Mar 2006 15:10:43 -0500 (EST) Received: by uga.edu (sSMTP sendmail emulation); Sun, 5 Mar 2006 15:10:43 -0500 Date: Sun, 5 Mar 2006 15:10:43 -0500 From: sramsay@uga.edu To: pgsql-sql@postgresql.org Subject: Re: functions in WHERE clause Message-ID: <20060305201043.GA14773@cantor.english.uga.edu> References: <20060305151652.GA14216@cantor.english.uga.edu> <20060305172635.GA77911@winnie.fuhr.org> <20060305174827.GA14433@cantor.english.uga.edu> <10317.1141582600@sss.pgh.pa.us> <20060305184903.GA11613@lachesis.english.uga.edu> <20060305113419.P64418@megazone.bigpanda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060305113419.P64418@megazone.bigpanda.com> X-PGP-Key: http://cantor.english.uga.edu/pubkey.asc User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.67 required=5 tests=[AWL=0.120, NO_REAL_NAME=0.55] X-Spam-Score: 0.67 X-Spam-Level: X-Archive-Number: 200603/102 X-Sequence-Number: 24448 On Sun, Mar 05, 2006 at 11:38:46AM -0800, Stephan Szabo wrote: > > But imagine instead that this function is more generic. You know > > that you're trying to get something that's equal to x and equal to > > y, but you don't know (until the function is called) what those > > rvalues should be. In other words, it's the 42 and the 47 that you > > don't know until runtime -- you always know what columns your > > searching on. > > Then you need to pass those in as well as something representing the row > that's being tested -- where clauses are filters on rows. The whole row > representation might be better than columns for some cases. > > For example: > > create table tt1(a int, b int); > create function f1(tt1, int) returns bool as 'select $1.a = $2' language > 'sql'; > > select * from tt1 where f1(tt1, 1); Eureka! That does it: CREATE OR REPLACE FUNCTION xpath(event, lquery) RETURNS bool AS $$ SELECT $1.ltree ~ $2; $$ LANGUAGE SQL; And it's fast (the event table is a view)! Interestingly, this version is very slow: CREATE OR REPLACE FUNCTION xpath(event, lquery) RETURNS bool AS $$ BEGIN RETURN $1.ltree ~ $2; END $$ LANGUAGE plpgsql STABLE; EXPLAIN shows lots of sequential scans when you try to do it this way. No inlining, perhaps? I guess I am still a little confused as to why you have to pass the table in as a parameter -- why you can't just do: RETURN event.ltree ~ $2; But I'll live . . . Thanks to one and all for the very generous assistance. I have learned much. Steve > The other option is to do this as a set returning function in the first > place rather than trying to do a wierd where clause thing. Mostly for syntactic clarity on the caller's end, but I understand what you're saying. -- Stephen Ramsay Assistant Professor Department of English University of Georgia email: sramsay@uga.edu web: http://cantor.english.uga.edu/ PGP Public Key ID: 0xA38D7B11