Rod Taylor <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
