From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Prentice <prentice(at)cisco(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mixed, named notation support |
Date: | 2009-08-09 17:00:07 |
Message-ID: | 14234.1249837207@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> --On 9. August 2009 12:27:53 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now that I've started to read this patch ... exactly what is the
>> argument for allowing a "mixed" notation (some of the parameters named
>> and some not)? ISTM that just serves to complicate both the patch
>> and the user's-eye view, for no real benefit.
> Hmm, Oracle has started supporting it in recent versions, too. So one
> advantage would be at least some sort of compatibility for another favorite
> database.
Mph. Does Oracle adopt the same semantics for what a mixed call means?
Because my next complaint was going to be that this definition was
poorly chosen anyway --- it seems confusing, unintuitive, and
restrictive. If the function is defined as having parameters (a,b,c)
then what does this do:
select foo(1, 2, 3 as b);
and what's the argument for having it do that rather than something
else?
If the behavior isn't *exactly* like Oracle in corner cases like this,
I think partial compatibility is worse than none. And in any case the
point stands that the more behavior you invent here, the more likely
you are to get blindsided by the eventual SQL standard.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2009-08-09 17:03:24 | Re: Split-up ECPG patches |
Previous Message | Bernd Helmle | 2009-08-09 16:51:20 | Re: mixed, named notation support |