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

From Greg Stark
Subject Re: Some array semantics issues
Date
Msg-id 878xvotntt.fsf@stark.xeocode.com
Whole thread Raw
In response to 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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> 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 seems utterly bogus. But the first case seems maybe
justifiable. maybe. 

In the past Postgres treated the array bounds as so insignificant they weren't
even worth preserving across a dump/restore. 

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 not
even sure how you would test it actually. Maybe something kludgy like
"'{}'::int[] || list = '{1,2}'" ?

I'm not entirely against the idea of making array bounds significant but I
guess we would need some convenient way of taking them out of the picture too.
Perhaps another equality operator.

-- 
greg



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: MERGE vs REPLACE
Next
From: "Dann Corbit"
Date:
Subject: Re: MERGE vs REPLACE