David E. Wheeler wrote:
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:
From a usability point of view, if we adopt the spec's syntax we have to
stop allowing => for any other purpose. Period.
What if we added a new "dual" type and limited the => operator only to that
type, being, ess
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:
> From a usability point of view, if we adopt the spec's syntax we have to
> stop allowing => for any other purpose. Period.
What if we added a new "dual" type and limited the => operator only to that
type, being, essentially, a constructor. Then hsto
2010/6/5 Greg Stark :
> On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane wrote:
>> No, that really isn't going to work: how will the parser know that the
>> names are not meant to match to actual named parameters of the function?
>> You could possibly do it with a special case for hstore() in the
>> gramm
Greg Stark writes:
> I wonder if we could offer something like VARIADIC but allows
> arbitrarily named parameters which get passed in a hstore-like hash
> instead of an array. Just thinking aloud here. I haven't thought about
> what this would mean in the function call api.
Yeah, with an extra ke
On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane wrote:
> No, that really isn't going to work: how will the parser know that the
> names are not meant to match to actual named parameters of the function?
> You could possibly do it with a special case for hstore() in the
> grammar, but we aren't going ther
Joseph Adams writes:
> Here's a thought: suppose we did use the foo (name => value) syntax
> for naming parameters. It could still be used in a very similar way
> for hstore:
> hstore(key1 => 'value1', key2 => 'value2')
No, that really isn't going to work: how will the parser know that the
nam
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams wrote:
> If I had to choose between => and := for parameter naming, I'd go with
> := because it seems more SQLish to me.
On second thought, => might actually be a very intuitive syntax for
defining dictionary types like hstore and json, since it matche
On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I sup
Jan Wieck wrote:
That is a sad wart that we should never have done, IMNSHO (it was
before my time or I would have objected ;-) ). But beyond that, = is
an operator in SQL and := is never an operator, IIRC.
As far as I can tell, this was already in the code when Bruce moved it
into core as
On 5/27/2010 11:52 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
David E. Wheeler wrote:
> On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
>
> > Now that it's pretty clear from Peter that the standard is not going to
> > change its choice here, I'll vote adding a WARNING each time an operator
> > called => is created, so that we get a chance to move later o
Tom Lane wrote:
> Bruce Momjian writes:
> > Thinking some more, what is the value of keeping => in hstore for 9.0?
>
> Backwards compatibility. You have not made any argument today that we
> have not been over many times before. I do not have time to argue
> about this today --- I have to go fi
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
> Now that it's pretty clear from Peter that the standard is not going to
> change its choice here, I'll vote adding a WARNING each time an operator
> called => is created, so that we get a chance to move later on.
Should support for ==> be adde
On Jun 3, 2010, at 8:54 AM, Tom Lane wrote:
>> Thinking some more, what is the value of keeping => in hstore for 9.0?
>
> Backwards compatibility. You have not made any argument today that we
> have not been over many times before. I do not have time to argue
> about this today --- I have to go
Bruce Momjian writes:
> Thinking some more, what is the value of keeping => in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix max_standby_delay.
Bruce Momjian writes:
> Is telling hstore users they have to change => to something else such a
> large major version incompatibility that it is worth supporting and
> documenting two syntaxes for parameter assignment? It is that calculus
> that has me questioning our approach.
Well it's not onl
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Are we sure we want hstore compatibility to drive this decision?
> >
> > hstore is what it is, and has been that way for a long time. We can't
> > just ignore it. And I don't think breaking it (and probably other code)
> > o
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Are we sure we want hstore compatibility to drive this decision?
>>
>> hstore is what it is, and has been that way for a long time. We can't
>> just ignore it. And I don't think breaking it (an
Tom Lane wrote:
> Bruce Momjian writes:
> > Are we sure we want hstore compatibility to drive this decision?
>
> hstore is what it is, and has been that way for a long time. We can't
> just ignore it. And I don't think breaking it (and probably other code)
> on zero notice is an acceptable outc
Bruce Momjian writes:
> Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
on zero notice is an acceptable outcome.
Peter Eisentraut wrote:
> On m?n, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
> > My feeling is that (a) there is no hurry to do anything about an
> > unreleased draft of the standard, and (b) perhaps Peter could lobby
> > the committee to change the standard before it does get published.
>
> Give
On mån, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
> My feeling is that (a) there is no hurry to do anything about an
> unreleased draft of the standard, and (b) perhaps Peter could lobby
> the committee to change the standard before it does get published.
Given that Oracle and DB2 already suppor
2010/6/1 Tom Lane :
> "David E. Wheeler" writes:
>> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>>> I was going to propose ==> across the board.
>
>> What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're forced to rename the operator.
> I'd
Bruce Momjian writes:
> Tom Lane wrote:
>> I'd still like to know exactly how hard the concrete has set on the
>> SQL spec draft, first. (Peter?)
> I don't know, but based on the fact it matches Oracle, I think it is
> pretty well set by now.
Eh? The SQL committee has a very long track record
On Mon, May 31, 2010 at 11:36 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>>> I was going to propose ==> across the board.
>
>> What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're force
Tom Lane wrote:
> "David E. Wheeler" writes:
> > On May 31, 2010, at 7:40 PM, Robert Haas wrote:
> >> I was going to propose ==> across the board.
>
> > What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're forced to rename the operator.
> I
"David E. Wheeler" writes:
> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>> I was going to propose ==> across the board.
> What about -> ?
hstore already uses that for something else.
Robert's idea isn't a bad one if we're forced to rename the operator.
I'd still like to know exactly how ha
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
> I was going to propose ==> across the board.
What about -> ?
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 31, 2010 at 9:24 PM, Florian Pflug wrote:
> On Jun 1, 2010, at 0:23 , Tom Lane wrote:
>> "David E. Wheeler" writes:
>>> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if
:= were to be used in this con
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
> "David E. Wheeler" writes:
>> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
>>> I don't have strong feelings about the timing - I'd be very surprised if :=
>>> were to be used in this context for any other purpose, so I don't think
>>> we'd be bit
"David E. Wheeler" writes:
> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
>> I don't have strong feelings about the timing - I'd be very surprised if :=
>> were to be used in this context for any other purpose, so I don't think we'd
>> be biting ourselves too much by just using that now. B
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
> I don't have strong feelings about the timing - I'd be very surprised if :=
> were to be used in this context for any other purpose, so I don't think we'd
> be biting ourselves too much by just using that now. But if we do that, we
> should d
Pavel Stehule writes:
> it's not important in this discussion. Important is using some usual
> symbol '=' or special symbol '=>'. Our syntax is probably only one
> possible solution in this moment (there are minimum controversy), bud
> semantic isn't best. Using same operator as assign statement u
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > MSSQL? Are you sure? This is the example posted in this thread:
> >
> > EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
> >
> > and it more matches our := syntax than => in its argument ordering.
> >
>
> I think you are seri
Bruce Momjian wrote:
MSSQL? Are you sure? This is the example posted in this thread:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
and it more matches our := syntax than => in its argument ordering.
I think you are seriously confused, or else you are seriously confu
2010/5/31 Bruce Momjian :
> Pavel Stehule wrote:
>> 2010/5/31 Bruce Momjian :
>> > Pavel Stehule wrote:
>> >> >> Part of the earlier discussion was about how => was a tempting
>> >> >> operator name and other users may well have chosen it precisely
>> >> >> because it's so evocative. But we don't a
Pavel Stehule wrote:
> 2010/5/31 Bruce Momjian :
> > Pavel Stehule wrote:
> >> >> Part of the earlier discussion was about how => was a tempting
> >> >> operator name and other users may well have chosen it precisely
> >> >> because it's so evocative. But we don't actually have any evidence of
> >>
2010/5/31 Bruce Momjian :
> Pavel Stehule wrote:
>> >> Part of the earlier discussion was about how => was a tempting
>> >> operator name and other users may well have chosen it precisely
>> >> because it's so evocative. But we don't actually have any evidence of
>> >> that. Does anyone have any ex
Pavel Stehule wrote:
> >> Part of the earlier discussion was about how => was a tempting
> >> operator name and other users may well have chosen it precisely
> >> because it's so evocative. But we don't actually have any evidence of
> >> that. Does anyone have any experience seeing => operators in
Tom Lane wrote:
Bruce Momjian writes:
Yes, but if we are going to have to honor "=>" eventually, shouldn't we
just do it now? Supporting := and => seems confusing.
Personally, I haven't accepted the "if" part of that, therefore I
feel no need to argue over the "then".
2010/5/31 Bruce Momjian :
> Greg Stark wrote:
>> On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
>> > Not breaking hstore, as well as any third-party modules that might be
>> > using that operator name. ?Did you not absorb any of the discussion
>> > so far?
>> >
>>
>> In fairness most of the disc
Greg Stark writes:
> If => is sql standard syntax then perhaps that changes the calculus.
Well, it *isn't* standard, yet at least. All we have is a report of the
current wording of a draft that's at least a year from release.
regards, tom lane
--
Sent via pgsql-hackers
Greg Stark wrote:
> On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
> > Not breaking hstore, as well as any third-party modules that might be
> > using that operator name. ?Did you not absorb any of the discussion
> > so far?
> >
>
> In fairness most of the discussion about breaking hstore was p
On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
> Not breaking hstore, as well as any third-party modules that might be
> using that operator name. Did you not absorb any of the discussion
> so far?
>
In fairness most of the discussion about breaking hstore was prior to
our learning that the sq
Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, but if we are going to have to honor "=>" eventually, shouldn't we
> > just do it now? Supporting := and => seems confusing.
>
> Personally, I haven't accepted the "if" part of that, therefore I
> feel no need to argue over the "then".
Right, I a
Bruce Momjian writes:
> Yes, but if we are going to have to honor "=>" eventually, shouldn't we
> just do it now? Supporting := and => seems confusing.
Personally, I haven't accepted the "if" part of that, therefore I
feel no need to argue over the "then".
regards, tom l
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> So as far as I can tell, no one is opposed to replacing "expr AS name"
> >> with "name := expr" in the named-parameter syntax. Obviously we had
> >> better get this done before beta2. Is anyone actually working on the
> >> code/doc
2010/5/31 Tom Lane :
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>>> with "name := expr" in the named-parameter syntax. Obviously we had
>>> better get this done before beta2. Is anyone actually working on the
>>> code/doc
Bruce Momjian writes:
> Tom Lane wrote:
>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>> with "name := expr" in the named-parameter syntax. Obviously we had
>> better get this done before beta2. Is anyone actually working on the
>> code/docs changes? If not, I'll pic
2010/5/31 Bruce Momjian :
> Tom Lane wrote:
>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>> with "name := expr" in the named-parameter syntax. Obviously we had
>> better get this done before beta2. Is anyone actually working on the
>> code/docs changes? If not, I'll
Tom Lane wrote:
> So as far as I can tell, no one is opposed to replacing "expr AS name"
> with "name := expr" in the named-parameter syntax. Obviously we had
> better get this done before beta2. Is anyone actually working on the
> code/docs changes? If not, I'll pick it up.
If we eventually ar
So as far as I can tell, no one is opposed to replacing "expr AS name"
with "name := expr" in the named-parameter syntax. Obviously we had
better get this done before beta2. Is anyone actually working on the
code/docs changes? If not, I'll pick it up.
regards, tom lane
Heikki Linnakangas writes:
> On 28/05/10 19:19, Josh Berkus wrote:
>> EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
>
> Once you solve the problem of finding the '='s in the source, replacing them
> is exactly the same effort regardless of what you replace them with.
I guess it would
On Fri, May 28, 2010 at 10:08 AM, Pavel Stehule wrote:
> 2010/5/28 Tom Lane :
>> Heikki Linnakangas writes:
Peter Eisentraut writes:
> How about
> select myfunc(a := 7, b := 6);
>>
>>> If we go with that, should we make some preparations to allow => in the
>>> future? Like provide a
Andrew Dunstan writes:
> Yeah. Whether or not we ever implement it really doesn't matter, IMO. We
> should not be in the business of taking an SQL standard piece of syntax
> and using it for some other purpose.
Evidently the 201x SQL standard has blindsided us twice: first by
defining a syntax
Josh Berkus writes:
> Since former SQL Server / Sybase apps are the most likely to use named
> parameter notation in PostgreSQL, having a syntax which could be ported
> using only "sed" would be nice.
I fear you're vastly overestimating the ability of sed to distinguish
between = used in this w
On 28/05/10 19:19, Josh Berkus wrote:
( parameter := value ) notation is not only consistent with what is used
inside pl/pgsql, it's also more consistent than "AS" with SQL Server's
named parameter notation, which is:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
Since former SQL Se
Bruce Momjian wrote:
Josh Berkus wrote:
Since former SQL Server / Sybase apps are the most likely to use named
parameter notation in PostgreSQL, having a syntax which could be ported
using only "sed" would be nice.
Relevant to the whole discussion, though ... is the conflicting SQL
stan
Josh Berkus wrote:
> Since former SQL Server / Sybase apps are the most likely to use named
> parameter notation in PostgreSQL, having a syntax which could be ported
> using only "sed" would be nice.
>
> Relevant to the whole discussion, though ... is the conflicting SQL
> standard syntax somet
What's poor about it? It probably comes from PLSQL which in turn got it
from Ada, so they aren't just making this up. I agree it's inconvenient
for us, but that's a different issue.
Further, the
( parameter := value ) notation is not only consistent with what is used
inside pl/pgsql, it's als
Tom Lane wrote:
Heikki Linnakangas writes:
Peter Eisentraut writes:
How about
select myfunc(a := 7, b := 6);
If we go with that, should we make some preparations to allow => in the
future? Like provide an alternative operator name for hstore's =>, and
add a note so
2010/5/28 Tom Lane :
> Heikki Linnakangas writes:
>>> Peter Eisentraut writes:
How about
select myfunc(a := 7, b := 6);
>
>> If we go with that, should we make some preparations to allow => in the
>> future? Like provide an alternative operator name for hstore's =>, and
>> add a note so
Heikki Linnakangas writes:
>> Peter Eisentraut writes:
>>> How about
>>> select myfunc(a := 7, b := 6);
> If we go with that, should we make some preparations to allow => in the
> future? Like provide an alternative operator name for hstore's =>, and
> add a note somewhere in the docs to disco
On 27/05/10 22:55, Tom Lane wrote:
Peter Eisentraut writes:
How about
select myfunc(a := 7, b := 6);
?
Hey, that's a thought. We couldn't have used that notation before
because we didn't have := as a separate token, but since I hacked that
in for plpgsql's benefit, I think it might be an eas
Andrew Dunstan writes:
> Bruce Momjian wrote:
>> One concern I have is that in PL/pgSQL, := and = behave the same, while
>> in SQL, they would not. That might cause confusion.
> I doubt there will be much confusion.
I agree. Bruce is ignoring the fact that they are *not* interchangeable
even i
Bruce Momjian wrote:
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use
FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll cr
Peter Eisentraut wrote:
> On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
> > > I think we should fix it now. Quick thought: maybe we could use
> > FOR
> > > instead of AS: select myfunc(7 for a, 6 for b);
> >
> > I'm afraid FOR doesn't work either; it'll create a conflict with the
> > spec-d
On Thu, May 27, 2010 at 02:55:54PM -0400, Robert Haas wrote:
> On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler
> wrote:
> > On May 27, 2010, at 9:59 AM, Tom Lane wrote:
> >
> >>> I think we should fix it now. Quick thought: maybe we could use FOR
> >>> instead of AS: select myfunc(7 for a, 6 f
2010/5/27 Tom Lane :
> Peter Eisentraut writes:
>> On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
>>> I'm afraid FOR doesn't work either; it'll create a conflict with the
>>> spec-defined SUBSTRING(x FOR y) syntax.
>
>> How about
>> select myfunc(a := 7, b := 6);
>> ?
>
> Hey, that's a thought
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > select myfunc(a := 7, b := 6);
Kinda like it myself.
> Question #1: is the SQL committee likely to standardize that out
> from under us, too?
Couldn't say on that one.
> Question #2: will ecpg have a problem with this? Or p
Peter Eisentraut writes:
> On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
>> I'm afraid FOR doesn't work either; it'll create a conflict with the
>> spec-defined SUBSTRING(x FOR y) syntax.
> How about
> select myfunc(a := 7, b := 6);
> ?
Hey, that's a thought. We couldn't have used that not
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
> > I think we should fix it now. Quick thought: maybe we could use
> FOR
> > instead of AS: select myfunc(7 for a, 6 for b);
>
> I'm afraid FOR doesn't work either; it'll create a conflict with the
> spec-defined SUBSTRING(x FOR y) syntax.
How
On Thu, May 27, 2010 at 2:59 PM, David E. Wheeler wrote:
> On May 27, 2010, at 11:55 AM, Robert Haas wrote:
>> Or we could use the Finnish word
>> epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
>> sure is not currently used in our grammar.
>
> I thought that was an Icelandic vo
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
> Or we could use the Finnish word
> epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
> sure is not currently used in our grammar.
I thought that was an Icelandic volcano.
Best,
David
--
Sent via pgsql-hackers mailing list (p
On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler wrote:
> On May 27, 2010, at 9:59 AM, Tom Lane wrote:
>
>>> I think we should fix it now. Quick thought: maybe we could use FOR
>>> instead of AS: select myfunc(7 for a, 6 for b);
>>
>> I'm afraid FOR doesn't work either; it'll create a conflict w
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
>> I think we should fix it now. Quick thought: maybe we could use FOR
>> instead of AS: select myfunc(7 for a, 6 for b);
>
> I'm afraid FOR doesn't work either; it'll create a conflict with the
> spec-defined SUBSTRING(x FOR y) syntax.
How about "I
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> In systems that have inheritance of composite types, this is used to
>> specify which type the value is supposed to be interpreted as (for
>> example, to treat the value as a supertype).
Why don't they just use CAST() syntax for that, instead of
2010/5/26 Peter Eisentraut :
> It turns out that the SQL standard uses the function call notation
>
> foo(this AS that)
>
> for something else:
>
> ::=
>
> ::= [ ]
>
> ::= [ [ { argument> }... ] ]
>
> ::=
> |
> |
>
> ::= AS user-defined type name>
>
> In systems that have inheri
On tor, 2010-05-27 at 10:51 +0300, Heikki Linnakangas wrote:
> On 27/05/10 10:49, Peter Eisentraut wrote:
> > On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
> >> On 27/05/10 03:57, Robert Haas wrote:
> >>> Being compatible with the SQL
> >>> standard and with Oracle is not to be taken
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anyth
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
> On 27/05/10 03:57, Robert Haas wrote:
> > Being compatible with the SQL
> > standard and with Oracle is not to be taken lightly.
>
> I seem to be alone believing that the SQL standard doesn't say anything
> about named function parame
On 27/05/10 10:16, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangas:
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangas:
AFAIU, the standard doesn't say anything about named parameters. Oracle
uses
=>, but as you said, that's ambiguous with the =>operator.
+1 for FOR.
2010/5/27 Abhijit Menon-Sen :
> At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
>>
>> I don't see any advantage of "FOR". We can change ir to support new
>> standard or don't change it.
>
> Adopting FOR would mean we don't use AS in a way that conflicts with the
> standard. That's its
2010/5/27 Heikki Linnakangas :
> On 27/05/10 09:50, Pavel Stehule wrote:
>>
>> 2010/5/27 Heikki Linnakangas:
>>>
>>> AFAIU, the standard doesn't say anything about named parameters. Oracle
>>> uses
>>> =>, but as you said, that's ambiguous with the => operator.
>>>
>>> +1 for FOR.
>>
>> I don't se
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
>
> I don't see any advantage of "FOR". We can change ir to support new
> standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's its only advantage. But I agree with you, I
On 27/05/10 09:50, Pavel Stehule wrote:
2010/5/27 Heikki Linnakangas:
AFAIU, the standard doesn't say anything about named parameters. Oracle uses
=>, but as you said, that's ambiguous with the => operator.
+1 for FOR.
I don't see any advantage of "FOR".
Any advantage over AS? It doesn't c
2010/5/27 Robert Haas :
> On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid => altogether as an operator name. (And no, I'm
2010/5/27 Tom Lane :
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I suppose the most painful thing a
2010/5/27 Heikki Linnakangas :
> On 27/05/10 02:09, alvherre wrote:
>>
>> Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
>>
>>> I think we should fix it now. Quick thought: maybe we could use FOR
>>> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
>>>
>>
>
> I think we should fix it now. Quick thought: maybe we could use FOR instead
> of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for
> this is 'paramname => value', but I think that has problems because of our
> possibly use of => as an operator - otherwise that would be
On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I sup
Robert Haas writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>> If we go with the spec's syntax I think we'd have no realistic choice
>> except to forbid => altogether as an operator name. (And no, I'm not
>> for that.)
> I suppose the most painful thing about doing that is that it wo
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?
As
On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
> alvherre writes:
>> The problem with the => operator seems best resolved as not accepting
>> such an operator in a function parameter, which sucks but we don't seem
>> to have a choice.
>
> "Sucks" is not the word; "utterly unacceptable" is the w
alvherre writes:
> The problem with the => operator seems best resolved as not accepting
> such an operator in a function parameter, which sucks but we don't seem
> to have a choice.
"Sucks" is not the word; "utterly unacceptable" is the word. Having an
expression mean different things depending
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname => value', but
On May 26, 2010, at 4:09 PM, alvherre wrote:
> The problem with the => operator seems best resolved as not accepting
> such an operator in a function parameter, which sucks but we don't seem
> to have a choice. Perhaps we could allow "=>" to resolve as the
> operator for the case the user really
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
> I think we should fix it now. Quick thought: maybe we could use FOR
> instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
> mechanism for this is 'paramname => value', but I think that has
> problems be
Peter Eisentraut wrote:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
::=
::= [ ]
::= [ [ { }... ] ]
::=
|
|
::= AS
In systems that have inheritance of composite types, this is used to
specify which type the
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
::=
::= [ ]
::= [ [ { }... ] ]
::=
|
|
::= AS
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be inte
100 matches
Mail list logo
