Hello
2008/8/24 Martijn van Oosterhout <[EMAIL PROTECTED]>:
> On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote:
>> So I feel that the proposal for labeled parameters as such is dead
>> in the water, and that the only usefulness this thread has had is
>> (re-) exploring the syntactic altern
On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote:
> So I feel that the proposal for labeled parameters as such is dead
> in the water, and that the only usefulness this thread has had is
> (re-) exploring the syntactic alternatives available for named params.
FWIW, I think the way that pyt
2008/8/24 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/8/23 Hannu Krosing <[EMAIL PROTECTED]>:
>>> Why not just use some standard record syntax, like
>
>> do you thing, so is it simpler?
>
> It's not about being "simpler", it's about pointing out that there ar
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/8/23 Hannu Krosing <[EMAIL PROTECTED]>:
>> Why not just use some standard record syntax, like
> do you thing, so is it simpler?
It's not about being "simpler", it's about pointing out that there are
ways to do what you need without creating compa
Hello
2008/8/24 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
>> 2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
>> > Hannu Krosing <[EMAIL PROTECTED]> writes:
>> >> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> >>> record or hash table - it's im
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
> 2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
> >>> record or hash table - it's implementation - second step. We have to
> >>> find syntax a
2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>>> record or hash table - it's implementation - second step. We have to
>>> find syntax and semantic now.
>
>> Why not just use some standard record syntax
2008/8/24 daveg <[EMAIL PROTECTED]>:
> On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>
>> > Hello
>> >
>> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> >>> If we're really
2008/8/23 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
>> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
>> >
>> >> How about we
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>
> > Hello
> >
> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
> >>> If we're really worried about it we can have a GUC for a few
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> record or hash table - it's implementation - second step. We have to
>> find syntax and semantic now.
> Why not just use some standard record syntax, like
> SELECT(value::type name, ...)
Yeah,
>>
>> At any point in this discussion has anyone explained why these
>> labels would
>> actually be a good idea?
>>
>
> it's allows smart libraries like SQL/XML
You could always just pass the label as an additional parameter. Which
is all this would be syntactic sugar for anyways. So it doesn
> So for a bit of useless syntactic sugar we should introduce conflicts with
> named parameters, conflicts with operators, introduce an un-sqlish syntax and
> remove a feature users have already made use of and introduce backwards
> compatibility issues for those users?
>
we talk only about "=>" sy
2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I thing, so it's possible - in this case. We should transform named
>> params to expr after syntax analyze.
>
> You're going to have a hard time making parentheses affect the behavior
> if you do it that way.
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
> Hello
>
> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
> >
> >> How about we poll -general and see what people say? I'll bet Tom a
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I thing, so it's possible - in this case. We should transform named
> params to expr after syntax analyze.
You're going to have a hard time making parentheses affect the behavior
if you do it that way.
regards, tom lane
--
S
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Hello
>
> 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>>> If we're really worried about it we can have a GUC for a few versions
>>> that turns off named parameter assignment. But I don't think we
Hello
2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> If we're really worried about it we can have a GUC for a few versions
>> that turns off named parameter assignment. But I don't think we
>> should compromise the design on the theory that s
On Friday 22 August 2008 07:41:30 Decibel! wrote:
> If we're really worried about it we can have a GUC for a few versions
> that turns off named parameter assignment. But I don't think we
> should compromise the design on the theory that some folks might be
> using that as an operator *and* c
Hello
2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
>> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
>
>> How about we poll -general and see what people say? I'll bet Tom a
>> beer that no one replies saying they've created a => operator (unl
Hello
2008/8/22 Teodor Sigaev <[EMAIL PROTECTED]>:
>>> How about we poll -general and see what people say? I'll bet Tom a beer
>>> that no one replies saying they've created a => operator (unless maybe
>>> PostGIS uses it).
>
> Hstore uses it:
> * text => text - creates hstore type from two te
How about we poll -general and see what people say? I'll bet Tom a
beer that no one replies saying they've created a => operator (unless
maybe PostGIS uses it).
Hstore uses it:
* text => text - creates hstore type from two text strings
select 'a'=>'b';
?column?
--
"a"=>"b"
--
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
> How about we poll -general and see what people say? I'll bet Tom a
> beer that no one replies saying they've created a => operator (unless
> maybe PostGIS uses it).
Does Oracle use => for
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
2008/8/20 Tom Lane <[EMAIL PROTECTED]>:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
I understand now why Oracle use => symbol for named params. This
isn't
used so operator - so implementation is trivial.
You really didn't understand the obje
2008/8/21 Asko Oja <[EMAIL PROTECTED]>:
> Would AS be harder to implement?
>
> select foo(10 AS a, 20 AS b);
> select foo(20 AS b, 20 AS a);
> select x(0 >= 1 AS a);
>
> other fantasies
> select foo(10 a, 20 b);
> select foo("a" 10, "b" 20);
no, I have it. Problem is in semantic. There are two fea
Would AS be harder to implement?
select foo(10 AS a, 20 AS b);
select foo(20 AS b, 20 AS a);
select x(0 >= 1 AS a);
other fantasies
select foo(10 a, 20 b);
select foo("a" 10, "b" 20);
regards,
Asko
On Wed, Aug 20, 2008 at 4:26 PM, Pavel Stehule <[EMAIL PROTECTED]>wrote:
> 2008/8/20 Tom Lane <[
2008/8/20 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I understand now why Oracle use => symbol for named params. This isn't
>> used so operator - so implementation is trivial.
>
> You really didn't understand the objection at all, did you?
>
> The point is not ab
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I understand now why Oracle use => symbol for named params. This isn't
> used so operator - so implementation is trivial.
You really didn't understand the objection at all, did you?
The point is not about whether there is any built-in operator named =
Hello
I understand now why Oracle use => symbol for named params. This isn't
used so operator - so implementation is trivial.
postgres=# create function x(a boolean) returns bool as $$select $1$$
language sql;
CREATE FUNCTION
Time: 5,549 ms
postgres=# select x(a => true);
x
---
t
(1 row)
Time
There may be a TODO in this thread somewhere, but I think this
particular suggestion has drifted pretty far from the problem that
Pavel was trying to solve.
...Robert
On Mon, Aug 18, 2008 at 11:19 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Is this a TODO?
>
>> > >> it's not possible in plpg
On Mon, 2008-08-18 at 11:19 -0400, Bruce Momjian wrote:
> Is this a TODO?
I don't think we have a TODO yet.
Maybe a TBD :)
> ---
>
> Hannu Krosing wrote:
> > On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
> > > 200
Is this a TODO?
---
Hannu Krosing wrote:
> On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
> > 2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> > > On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
> > >> Hannu
>
On Mon, 2008-08-18 at 10:51 +0300, Peter Eisentraut wrote:
> Am Saturday, 16. August 2008 schrieb Hannu Krosing:
> > A "label" is the same thing as "variable"/"attribute"/"argument name" in
> > all programming languages I can think of. Why do you need two kinds of
> > argument names in postgreSQL
On Mon, 2008-08-18 at 08:53 +0200, Pavel Stehule wrote:
> 2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
> >> Hannu
> >>
> >> it's not possible in plpgsql, because we are not able iterate via record.
> >
> > just add function for iterating o
Am Saturday, 16. August 2008 schrieb Hannu Krosing:
> A "label" is the same thing as "variable"/"attribute"/"argument name" in
> all programming languages I can think of. Why do you need two kinds of
> argument names in postgreSQL ?
>
> maybe you are after something like keyword arguments in pytho
2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
>> Hannu
>>
>> it's not possible in plpgsql, because we are not able iterate via record.
>
> just add function for iterating over record :)
it's not easy, when iterating should be fast - when rec
> uups, completely forgot dual use of = for both assignment and
> comparison.
>
> Maybe we can do without any "keyword arguments" or "labeled function
> params" if we define a way to construct records in-place.
That sounds a lot cleaner to me.
> something like
> RECORD( 'Zdanek'::text AS name, 22
On Sun, 2008-08-17 at 18:24 -0400, Robert Haas wrote:
> > Actually the most "natural" syntax to me is just f(name=value) similar
> > to how UPDATE does it. It has the added benefit of _not_ forcing us to
> > make a operator reserved (AFAIK "=" can't be used to define new ops)
>
> The problem with
> Actually the most "natural" syntax to me is just f(name=value) similar
> to how UPDATE does it. It has the added benefit of _not_ forcing us to
> make a operator reserved (AFAIK "=" can't be used to define new ops)
The problem with this is that
SELECT foo(a = b)
...is already valid syntax. It
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote:
> Hannu
>
> it's not possible in plpgsql, because we are not able iterate via record.
just add function for iterating over record :)
create or replace function json(r record)
returns varchar as $$
select '[' || array_to_string(
array(
2008/8/17 Asko Oja <[EMAIL PROTECTED]>:
> Not able to means not implementable o not implemented ?
Almost not implementable - plpgsql is too static language.
>
> On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule <[EMAIL PROTECTED]>
> wrote:
>>
>> Hannu
>>
>> it's not possible inNot able to plpgsql,
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
>> On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
>>> 2008/8/16 Decibel! <[EMAIL PROTECTED]>:
>>> > SQL-like would be value AS name, but I'm not a fan of putting the value
>>> > before the name. And
Not able to means not implementable o not implemented ?
On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule <[EMAIL PROTECTED]>wrote:
> Hannu
>
> it's not possible inNot able to plpgsql, because we are not able iterate
> via record.
>
> Pavel
>
> 2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Su
Hannu
it's not possible in plpgsql, because we are not able iterate via record.
Pavel
2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote:
>> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> > Actually the most "natural" syntax to me is just f(name=value)
On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Actually the most "natural" syntax to me is just f(name=value) similar
> > to how UPDATE does it. It has the added benefit of _not_ forcing us to
> > make a operator reserved (AFAIK "=" can't be used
2008/8/17 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
>> 2008/8/16 Decibel! <[EMAIL PROTECTED]>:
>> > On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
>> >>>
>> >>> "value AS name", on the other hand, accomplishes the same in a more
>> >>> SQL-looki
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Actually the most "natural" syntax to me is just f(name=value) similar
> to how UPDATE does it. It has the added benefit of _not_ forcing us to
> make a operator reserved (AFAIK "=" can't be used to define new ops)
*What* are you thinking?
On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote:
> 2008/8/16 Decibel! <[EMAIL PROTECTED]>:
> > On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
> >>>
> >>> "value AS name", on the other hand, accomplishes the same in a more
> >>> SQL-looking fashion with no new reserved word (since AS is al
2008/8/16 Decibel! <[EMAIL PROTECTED]>:
> On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
>>>
>>> "value AS name", on the other hand, accomplishes the same in a more
>>> SQL-looking fashion with no new reserved word (since AS is already
>>> fully reserved).
>>
>> would it be more natural / SQL-li
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
"value AS name", on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use "value AS name" or "name AS
value" ?
IMHO, *nat
On Sat, 2008-08-16 at 08:44 +0200, Pavel Stehule wrote:
> Hello
> >> "value AS name", on the other hand, accomplishes the same in a more
> >> SQL-looking fashion with no new reserved word (since AS is already
> >> fully reserved).
> >
> > would it be more natural / SQL-like to use "value AS name"
On Saturday 16 August 2008 09:38:41 Pavel Stehule wrote:
> because you have to write labels, where labels are equal with column
> names. I would to add same comfort like SQL/XML functions.
Just a thought: You might be able to design this in some way to work on top of
named parameter calling. Def
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> or just use := operator?
You're still commandeering an operator name that wasn't reserved before.
This one doesn't even have the feeble excuse of being Oracle-compatible.
regards, tom lane
--
Sent via pgsql-hackers mailing li
Hello
2008/8/15 Hannu Krosing <[EMAIL PROTECTED]>:
> On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> > Random googling shows me that Oracle appears to use a syntax like
>> > name => value
>> > This is actually a feature that I would like to
2008/8/15 Hannu Krosing <[EMAIL PROTECTED]>:
> On Fri, 2008-08-15 at 14:54 +0200, Pavel Stehule wrote:
>> 2008/8/15 Peter Eisentraut <[EMAIL PROTECTED]>:
>> > Am Thursday, 14. August 2008 schrieb Pavel Stehule:
>> >> I propose enhance current syntax that allows to specify label for any
>> >> functi
On Fri, 2008-08-15 at 14:54 +0200, Pavel Stehule wrote:
> 2008/8/15 Peter Eisentraut <[EMAIL PROTECTED]>:
> > Am Thursday, 14. August 2008 schrieb Pavel Stehule:
> >> I propose enhance current syntax that allows to specify label for any
> >> function parameter:
> >>
> >> fcename(expr [as label], ..
On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Random googling shows me that Oracle appears to use a syntax like
> > name => value
> > This is actually a feature that I would like to see implemented soonish, so
> > if
> > anyone has input
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Random googling shows me that Oracle appears to use a syntax like
> name => value
> This is actually a feature that I would like to see implemented soonish, so
> if
> anyone has input on the possible syntax consequences, please comment.
We've be
Hello
2008/8/15 Peter Eisentraut <[EMAIL PROTECTED]>:
> Am Friday, 15. August 2008 schrieb Tom Lane:
>> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> > How is this supposed to interact with argument names ?
>>
>> Yeah, the real problem with this proposal is that it conscripts a syntax
>> that we'll
Am Friday, 15. August 2008 schrieb Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > How is this supposed to interact with argument names ?
>
> Yeah, the real problem with this proposal is that it conscripts a syntax
> that we'll probably want to use in the future for argument-name-based
>
2008/8/15 Peter Eisentraut <[EMAIL PROTECTED]>:
> Am Thursday, 14. August 2008 schrieb Pavel Stehule:
>> I propose enhance current syntax that allows to specify label for any
>> function parameter:
>>
>> fcename(expr [as label], ...)
>> fcename(colname, ...)
>>
>> I would to allow same behave of c
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
> I propose enhance current syntax that allows to specify label for any
> function parameter:
>
> fcename(expr [as label], ...)
> fcename(colname, ...)
>
> I would to allow same behave of custom functions like xmlforest function:
> postgres=# sel
2008/8/15 Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> How is this supposed to interact with argument names ?
>
> Yeah, the real problem with this proposal is that it conscripts a syntax
> that we'll probably want to use in the future for argument-name-based
> parame
2008/8/14 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
>> Hello
>>
>> I propose enhance current syntax that allows to specify label for any
>> function parameter:
>>
>> fcename(expr [as label], ...)
>> fcename(colname, ...)
>
> also fcename(localvar,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> How is this supposed to interact with argument names ?
Yeah, the real problem with this proposal is that it conscripts a syntax
that we'll probably want to use in the future for argument-name-based
parameter matching. The proposed behavior is not nearly
On Thu, 2008-08-14 at 11:56 +0200, Pavel Stehule wrote:
> Hello
>
> I propose enhance current syntax that allows to specify label for any
> function parameter:
>
> fcename(expr [as label], ...)
> fcename(colname, ...)
also fcename(localvar, ...) if called from another function ?
How is this sup
Hello
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions like xmlforest function:
postgres=# select xmlforest(a) from foo;
xmlforest
---
10
(1 ro
67 matches
Mail list logo
