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
