To: Ang Chin Han <angch@bytecraft.com.my>
Cc: Greg Stark <gsstark@mit.edu>, Josh Berkus <josh@agliodbs.com>,
	Stefan Bill <sjb26@yahoo.com>, pgsql-sql@postgresql.org
Subject: Re: LEAST and GREATEST functions? 
In-reply-to: <3F0277E6.9090906@bytecraft.com.my> 
References: <20030630201057.14507.qmail@web13905.mail.yahoo.com>
	<200306302032.23113.josh@agliodbs.com>
	<87d6gu2otf.fsf@stark.dyndns.tv>
	<3F025942.6000507@bytecraft.com.my>
	<24828.1057124242@sss.pgh.pa.us>
	<3F0277E6.9090906@bytecraft.com.my>
Comments: In-reply-to Ang Chin Han <angch@bytecraft.com.my>
	message dated "Wed, 02 Jul 2003 14:12:54 +0800"
Date: Wed, 02 Jul 2003 02:36:44 -0400
Message-ID: <25189.1057127804@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ang Chin Han <angch@bytecraft.com.my> writes:
> I'd say we need to have LEAST and GREATEST at least somewhere in contrib 
> (as functions) if not core, to make transition from other RDBMS to 
> postgresql easier.
> A brief test shows that we would incur quite a performance penalty (I 
> compared COALESCE with coalesce_sql_function) if it isn't hardwiring.

In 7.4 I think that tradeoff will change significantly.  SQL functions
are polymorphic thanks to Joe Conway, and they're inline-able thanks
to me ;-), so there's really no difference between writing the strictly
SQL-compliant

SELECT CASE WHEN a>b THEN a ELSE b END FROM foo;

and writing

create function greatest(anyelement, anyelement) returns anyelement as
'select case when $1>$2 then $1 else $2 end' language sql;

SELECT greatest(a,b) FROM foo;

You do have to create several greatest() functions for different numbers
of arguments, but not one for each datatype you want to handle.

I have not seen enough requests for a native LEAST/GREATEST
implementation to make me think we need to do more than this...
certainly I'd rather spend development effort on general facilities
like polymorphism and inlining than on creating one-use facilities
like built-in LEAST/GREATEST.

			regards, tom lane