Re: It's June 1; do you know where your release is? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: It's June 1; do you know where your release is?
Date
Msg-id 21109.1244156328@sss.pgh.pa.us
Whole thread Raw
In response to Re: It's June 1; do you know where your release is?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: It's June 1; do you know where your release is?  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
One of the other open items is:

>> contrib/intarray opclass definition needs updating
>>   tgl says: done, but there's another problem; see also bug #4806

The state of play on this is:

* GIN cannot find items that generate no index entries, such as empty
arrays or empty text documents.

* This is the Wrong Thing for certain operators, notably array
inclusion: "x <@ array[1]" ought to find empty-array values of x.

* Fixing this is quite nontrivial, although it seems doable (basically,
"empty" values need to be entered with some sort of placeholder key).
Behavior for, eg, arrays containing NULL elements also needs to be
thought about.

* However, it's been broken for awhile (since 8.2) and nobody complained
until recently.  So it seems acceptable to just put the issue on TODO
and leave it unfixed for 8.4.

* But ... the patch I applied to fix this issue
http://archives.postgresql.org/message-id/17021.1234474178@sss.pgh.pa.us
means that users of contrib/intarray might be subject to this
inconsistency where they were not before.  The contrib/intarray
operators were defined to not succeed for empty arrays, which might be
mathematically wrong but it made them consistent with the index
behavior.  Of course, they were also *in*consistent with the
identically-named core array operators.

It seems we have two reasonable possibilities for 8.4: revert that patch
and keep contrib/intarray's behavior the same as it was, or leave the
patch in and document that there was a behavioral change.

Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.4b2 tsearch2 strange error
Next
From: Bruce Momjian
Date:
Subject: Re: User-facing aspects of serializable transactions