Jim Nasby writes:
> One could theoretically construct a custom "type" that followed more
> traditional semantics, but then you'd lose all the syntax... which I
> suspect would make any such "type" all but unusable. The other problem
> would be having it deal with any other data type, but at lea
On 12/22/15 12:01 PM, Tom Lane wrote:
Yury Zhuravlev writes:
If you break backwards compatibility, it can be done arrays
similar to C/C++/Python/Ruby and other languages style?
I'm sorry to bring up this thread again...
I am not sure just exactly how incompatible that would be, but surely it
Pavel Stehule writes:
> 2015-12-22 18:34 GMT+01:00 Robert Haas :
>> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
>>> ISTM that if we'd had Yury's code in there from the beginning, what we
>>> would define this as meaning is "a[3:4][:5]", ie the implied range runs
>>> from whatever the array
2015-12-22 18:34 GMT+01:00 Robert Haas :
> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
> > I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to
> be
> > omitted, for example "a[4:]" means "the slice extending from element 4 to
> > the last element of a". It strikes me th
On 12/22/2015 10:01 AM, Robert Haas wrote:
On Tue, Dec 22, 2015 at 12:55 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
ISTM that if we'd had Yury's code in there from the beginning, what we
would define this as meaning is "a[3:4][:5]", ie the impl
On Tue, Dec 22, 2015 at 12:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
>>> ISTM that if we'd had Yury's code in there from the beginning, what we
>>> would define this as meaning is "a[3:4][:5]", ie the implied range runs
>>> from whatever th
Yury Zhuravlev writes:
> If you break backwards compatibility, it can be done arrays
> similar to C/C++/Python/Ruby and other languages style?
> I'm sorry to bring up this thread again...
I am not sure just exactly how incompatible that would be, but surely it
would break enormously more code th
Robert Haas writes:
> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
>> ISTM that if we'd had Yury's code in there from the beginning, what we
>> would define this as meaning is "a[3:4][:5]", ie the implied range runs
>> from whatever the array lower bound is up to the specified subscript.
>
This would make no difference of course for the common case where the
array lower bound is 1, but it seems a lot less arbitrary when it isn't.
So I think we should strongly consider changing it to mean that, even
though it would be non-backwards-compatible in such cases.
Comments?
If you break
On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote:
> I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to be
> omitted, for example "a[4:]" means "the slice extending from element 4 to
> the last element of a". It strikes me that there's an improvement we
> could easily make for
I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to be
omitted, for example "a[4:]" means "the slice extending from element 4 to
the last element of a". It strikes me that there's an improvement we
could easily make for the case where a mixture of slice and non-slice
syntax app
11 matches
Mail list logo
