Re: Some array semantics issues - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Some array semantics issues
Date
Msg-id 873blwtl5i.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Some array semantics issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Some array semantics issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Some array semantics issues  (David Fetter <david@fetter.org>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> 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 {1,2} is a
list of two numbers, and {{1,2,},{3,4}} is a list of two lists. They aren't
the same and they don't even contain the same thing.

It occurs to me that it would also make sense to have an operator that
considered the arrays in an order-insensitive comparison. 

It all depends on what you're using the arrays to represent.

If you're implementing something where each slot of the array corresponds to
some specific meaning then you need the array bounds included.

If you're representing stacks where the array bounds march up as they're used
then you don't really want to include the array bounds in your comparison.

If you're representing a denormalized one-to-many relationship (being aware of
all the associated pros and cons of denormalization of course) then you really
don't care about the order at all.

Personally I can't really think of any cases where the shape of the array
doesn't matter though.

-- 
greg



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: MERGE vs REPLACE
Next
From: Bruno Wolff III
Date:
Subject: Re: forcing returned values to be binary