From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ang Chin Han <angch(at)bytecraft(dot)com(dot)my> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Josh Berkus <josh(at)agliodbs(dot)com>, Stefan Bill <sjb26(at)yahoo(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: LEAST and GREATEST functions? |
Date: | 2003-07-02 06:36:44 |
Message-ID: | 25189.1057127804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Ang Chin Han <angch(at)bytecraft(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ang Chin Han | 2003-07-02 07:11:01 | Re: LEAST and GREATEST functions? |
Previous Message | Jonathan Man | 2003-07-02 06:21:25 | SQL |