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, well, I'm
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
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
bugs in earlier
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
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 anyway.
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
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, and the
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 second case
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 ordinary
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:
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
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 are
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 point of view
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 name?
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
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 from
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 reloading
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 least if
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
19 matches
Mail list logo
