Tom Lane wrote:
Given the just-committed changes to avoid having array_push/array_cat
generate non-spec lower bounds unnecessarily, do you still think it's
important to have a variant of array comparison that ignores lower
bounds?
ISTM that ignoring lower bounds is definitely something that viol
Greg Stark <[EMAIL PROTECTED]> writes:
> [ this is back up-thread a bit ]
> And changing that would make it harder to test just the contents of the array
> without having to match bounds as well. That is, You couldn't say "list =
> '{1,2}'" to test if the array contained 1,2. You would have to, wel
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If we can't use an OID to identify a data type
>> completely, we're going to have lots of problems.
> You only really need two pieces of information to uniquely identify an
> array data type -- the OID of the (leaf-node) scalar elements,
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
... My hope was that eventually anyarray I/O functions
could eliminate the need to create an array type for every data type you
wanted to use as an array element.
Interesting thought, but then how do you declare the type of an array
colum
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How about changing them so that the lower bound of the right-hand array
>> is preserved, rather than decreased by one?
> That seems reasonable. I'll do it if you'd like...
I'll take care of it --- I'm still hacking in that general area a
Tom Lane wrote:
AFAICS the only cases that give rise to arrays with lower bounds other
than one are:
* direct entry of a literal with explicit lower bound;
* assignment to a subscript or slice below 1;
* array_prepend (and the N/N+1-dimension case of array_cat).
I don't t
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I don't have a lot of use for arguments that go "we should remove any
>> functionality that's not in the spec" ... ISTM that variable lower
>> bounds are clearly useful for some applications, and even if they had
>> bu
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
Joe Conway <[EMAIL PROTECTED]> writes:
First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at
Tom Lane <[EMAIL PROTECTED]> writes:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > First, the spec only allows arrays to have a lower bound of 1. That
> > requirement simplifies a whole lot of things. I don't think that many
> > people actually depend on other than 1 as a lower bound (or at leas
Joe Conway <[EMAIL PROTECTED]> writes:
> First, the spec only allows arrays to have a lower bound of 1. That
> requirement simplifies a whole lot of things. I don't think that many
> people actually depend on other than 1 as a lower bound (or at least if
> they do, they weren't dumping and reloa
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> writes:
Well, in that case what do you think about
{{1,2},{3,4},{5,6},{7,8}}
vs
{{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so fro
David Fetter <[EMAIL PROTECTED]> writes:
> On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
>> It occurs to me that it would also make sense to have an operator
>> that considered the arrays in an order-insensitive comparison.
> That sounds more like the SQL:2003 MULTISET, which is ess
On Wed, Nov 16, 2005 at 03:03:53PM -0500, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I could go for a separate operator that has the current behavior
> > (might as well ignore number of dimensions too, if we're going to
> > ignore bounds). Any thoughts about the operator na
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Well, in that case what do you think about
>> {{1,2},{3,4},{5,6},{7,8}}
>> vs
>> {{1,2,3,4},{5,6,7,8}}
> In the first case the first element is {1,2} and in the second case the first
> element is {1,2,3,4} so from my
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, in that case what do you think about
> {{1,2},{3,4},{5,6},{7,8}}
> vs
> {{1,2,3,4},{5,6,7,8}}
In the first case the first element is {1,2} and in the second case the first
element is {1,2,3,4} so from my point of view there's no way these a
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I could go for a separate operator that has the current behavior
>> (might as well ignore number of dimensions too, if we're going to
>> ignore bounds). Any thoughts about the operator name?
> Well to me these are tw
Tom Lane <[EMAIL PROTECTED]> writes:
> I could go for a separate operator that has the current behavior
> (might as well ignore number of dimensions too, if we're going to
> ignore bounds). Any thoughts about the operator name?
Well to me these are two different cases. At least the way I see it
Greg Stark <[EMAIL PROTECTED]> writes:
> And changing that would make it harder to test just the contents of the array
> without having to match bounds as well.
Fair point, but currently it's impossible to make a comparison that
*does* consider the bounds, which one would think would be the ordina
Tom Lane <[EMAIL PROTECTED]> writes:
> regression=# select '[0:2]={1,2,3}'::int[] = '{1,2,3}'::int[];
> ?column?
> --
> t
> (1 row)
>
> regression=# select '{1,2,3,4}'::int[] = '{{1,2},{3,4}}'::int[];
> ?column?
> --
> t
> (1 row)
>
> This seems pretty bogus as well.
The
While hacking on the nulls-in-arrays addition, I noticed a couple of
behaviors that seem a bit bogus to me.
First, array slicing returns NULL any time the requested slice falls
completely outside the array bounds. For instance
regression=# select ('{1,2,3}'::int[])[2:4];
int4
---
{2,3}
(1
20 matches
Mail list logo
