Re: mixed, named notation support

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

In response to

Responses

Browse pgsql-hackers by date

  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