Date: Sun, 1 Jun 2003 11:15:59 -0500
Subject: Re: generic return for functions 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Rod Taylor <rbt@rbt.ca>, Bruce Momjian <pgman@candle.pha.pa.us>,
	pgsql-sql@postgresql.org
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Avi Schwartz <avi@CFFtechnologies.com>
In-Reply-To: <26866.1054482407@sss.pgh.pa.us>
Message-Id: <54D7C9C2-944C-11D7-ACB0-000393AE5044@CFFtechnologies.com>
Content-Transfer-Encoding: 7bit

On Sunday, Jun 1, 2003, at 10:46 America/Chicago, Tom Lane wrote:

> Rod Taylor <rbt@rbt.ca> writes:
>>> thing that causes me some minor grief is the fact that currently 
>>> you=20
>>> cannot have default values to function parameters, a feature we use 
>>> a=20
>>> lot.
>
>> fn(integer, integer, integer default 32)
>> select fn(integer, integer); <- Third argument would be '32'?
>> When PostgreSQL gets named parameters the above probably makes sense 
>> to
>> add.
>
>> A TODO item?
>
> That isn't ever going to happen.  We have enough difficulty resolving
> overloaded functions as it is.  If we couldn't even be sure how many
> arguments there were supposed to be, it'd become completely 
> intractable.
>
> You can however achieve similar effects at the user level by adding
> auxiliary functions: declare fn(int,int) as a one-line SQL function
> that calls fn($1, $2, 32).
>
> 			regards, tom lane

I understand why it will not be implemented with overloaded functions.  
Is there a possibility to allow this only for functions that are not 
overloaded?  The SQL function solution is really not going to help in 
my case since the function builds a select statement dynamically based 
on which parameters have a non-null value.  The number of parameters is 
something like 12 or 13 and the control on which parameters are set is 
determined by a complex combination of program logic and user 
selections.  What I did to solve this problem was to force all 
variables to be initialized to null and then set the non-null ones 
before the call to the function.

On another note, somewhat related, when we started looking at a 
replacement to SQL Server 7, I looked at SAPDB, MySQL and now 
PostgreSQL.  MySQL lost immediately since the current version is 
missing a lot of functionality we were looking for.  I was not 
impressed by SAPDB's performance, their documentation is extremely hard 
to follow and I found the database very hard to manage.  So far 
PostgreSQL seems to be the best choice for us.  I am yet to find a show 
stopper and the speed is fantastic.  I didn't do extensive comparisons 
yet and I don't have hard numbers, but from what I have seen so far, 
PostgreSQL 7.3.2 is at least as fast as SQL Server 7 in real life 
situations (Of course count(*) is still much faster in SQL Server for 
very large tables (some of our tables are > 5M rows) :-) .  What makes 
it more impressive is the fact that SS runs on a 4 CPU machine with 2 
GB of memory while PostgreSQL on a single CPU machine with 384M memory 
running SuSE 8.2.  In the near future I will be moving the PostgreSQL 
database to a similar configuration as SS.  It will be interested to 
compare them then.

To PostgreSQL developers, thank you for a great product!

Avi
-- 
Avi Schwartz
avi@CFFtechnologies.com