From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Calling PL functions with named parameters |
Date: | 2004-08-14 03:12:36 |
Message-ID: | 809.1092453156@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> Would it be any better to allow
> SELECT blah(1,DEFAULT);
Not a lot. If there is more than one 2-parameter blah(), how do you
pick? The DEFAULT gives you no clue at all about the type of the
second parameter...
I think if we wanted to do something like this, the right way would be
that "create function foo(f1 text, f2 int default 42)" implicitly
creates a second function "foo(f1 text)", and we make no change to the
matching rules. But managing this seems mighty messy --- for instance,
we don't presently have any concept of hidden or second-class-citizen
entries in pg_proc, but we'd have to create one to keep the implicitly
created functions out of your face in pg_dump, psql \df, etc. And
again, it's not really giving you anything you can't have today.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-14 03:21:23 | Re: PITR on Windows? |
Previous Message | Tom Lane | 2004-08-14 03:04:05 | Re: [Fwd: Re: [pgsql-hackers-win32] Import from Linux to |