Re: mixed, named notation support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: mixed, named notation support
Date
Msg-id 14234.1249837207@sss.pgh.pa.us
Whole thread Raw
In response to Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
Bernd Helmle <mailings@oopsware.de> writes:
> --On 9. August 2009 12:27:53 -0400 Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: mixed, named notation support
Next
From: Michael Meskes
Date:
Subject: Re: Split-up ECPG patches