pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Josh Berkus <josh@agliodbs.com>
To: 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:45:38 -0700
Message-ID: <200306011145.38977.josh@agliodbs.com> (raw)
In-Reply-To: <54D7C9C2-944C-11D7-ACB0-000393AE5044@CFFtechnologies.com>
References: <54D7C9C2-944C-11D7-ACB0-000393AE5044@CFFtechnologies.com>

Avi,

> 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?  

Unfortunately, no.  There's simply no way for the database to tell the 
difference between a function call relying on defaults, and one with the 
wrong parameters.  SQL Server's approach with defaults works *because* SQL 
Server does not support overloaded procedures.

> 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.

This sounds like a good solution to me.

BTW, named parameters for PostgreSQL Functions are on the to-do list, but I 
don't think anyone is currently working on them.

> 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.

That's a very nice testimonial!  Thanks.

BTW, you will probably wish to join the PGSQL-Performance mailing list to make 
sure that you can tune your PostgreSQL database properly.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco



view thread (8+ messages)

Message-ID: <200306011145.38977.josh@agliodbs.com>
Permalink:  ../200306011145.38977.josh@agliodbs.com/
Also on:    postgresql.org/message-id/200306011145.38977.josh@agliodbs.com

 · 

reply

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: josh@agliodbs.com, 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: <200306011145.38977.josh@agliodbs.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