Re: Server may segfault when using slices on int2vector - Mailing list pgsql-bugs

Le samedi 23 novembre 2013 15:39:39 Tom Lane a =E9crit :
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> > On 19.11.2013 16:24, Ronan Dunklau wrote:
> >> [ this crashes: ]
> >> select
> >> a.indkey[1:3],
> >> a.indkey[1:2]
> >> from pg_index as a
> >=20
> > I don't think it's safe to allow slicing int2vectors (nor oidvector=
s).
> > It seems all too likely that the result violates the limitations of=

> > int2vector. In addition to that segfault, the array returned is 1-b=
ased,
> > not 0-based as we assume for int2vectors. One consequence of that i=
s
> > that if you COPY the value out in binary format and try to read it =
back,
> > you'll get an error.
> >=20
> > So I think we should just not allow slicing oidvectors, and throw a=
n
> > error. You can cast from int2vector to int2[], and slice and dice t=
hat
> > as much as you want, so it's not a big loss in functionality.
>=20
> I think more useful is to automatically cast up to int2[], rather tha=
n
> make the user write something as ugly as "(a.indkey::int2[])[1:3]".
> This case is really pretty similar to what we have to do when handlin=
g
> domains over arrays; int2vector could be thought of as a domain over
> int2[] that constrains the allowed subscripting.  And what we do for
> those is automatically cast up.
>=20
> With that thought in mind, I tried tweaking transformArrayType() to
> auto-cast int2vector and oidvector to int2[] and oid[].  That resolve=
s
> this crash without throwing an error.  On the other hand, it causes
> assignment to an element or slice of these types to throw an error, w=
hich
> strikes me as a Good Thing because otherwise such an assignment could=

> likewise result in a value violating the subscript constraints of the=
se
> types.  We could if we liked fix that by providing a cast from int2[]=
 to
> int2vector that checks the subscript constraints, but like you I'm no=
t
> thinking it's worth the trouble.  There are certainly no cases in the=

> system catalogs where we want to support such manual assignments.
>=20
> While testing that I discovered an independent bug in
> transformAssignmentSubscripts: the "probably shouldn't fail" error
> reporting code doesn't work because "result" has already been set to =
NULL.
> We should fix that as per attached whether or not we choose to resolv=
e
> Ronan's bug this way.
>=20
> The attached patch is just a quick draft for testing; it needs more w=
ork
> on the nearby comments, and the OIDs of int2[] and oid[] should be na=
med
> by #define's in pg_type.h not by literal constants.  If there are no
> objections, I'll clean it up and commit.
>=20
> =09=09=09regards, tom lane

Thank you for the match, I saw it got commited.

I have some more questions, however not directly related to this bug.

Casting from int2vector to int2[] returns a zero-indexed array, but sli=
cing an=20
int2vector returns a one-indexed array. This behavior is consistent wit=
h=20
slicing in general, which always returns 1 indexed arrays, but I found =
it=20
surprising, especially when writing a query like this:

  select ('1 2'::int2vector)[0:1] =3D ('1 2'::int2vector)::int2[];

I would have expected to return true, but it actually isn't because one=
 array=20
is zero-indexed and the other one is not.

Is there a more convenient way to change the lower bound of an array th=
an to=20
slice it ?


Thank you very much.

--=20
Ronan Dunklau
http://dalibo.com - http://dalibo.org