From: Avi Schwartz <avi@CFFtechnologies.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rod Taylor <rbt@rbt.ca>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-sql@postgresql.org
Subject: Re: generic return for functions
Date: Sun, 1 Jun 2003 11:15:59 -0500
Message-ID: <54D7C9C2-944C-11D7-ACB0-000393AE5044@CFFtechnologies.com> (raw)
In-Reply-To: <26866.1054482407@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: avi@CFFtechnologies.com, tgl@sss.pgh.pa.us, rbt@rbt.ca, pgman@candle.pha.pa.us
Subject: Re: generic return for functions
In-Reply-To: <54D7C9C2-944C-11D7-ACB0-000393AE5044@CFFtechnologies.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox