Le mercredi 20 novembre 2013 13:43:48 Heikki Linnakangas a =E9crit :
> On 19.11.2013 16:24, Ronan Dunklau wrote:
> > Hello.
> >=20
> > While building a query on the pg_index relation, I came accross a b=
ug
> > which
> > simplest form is manifested as this:
> >=20
> > select
> >=20
> > a.indkey[1:3],
> > a.indkey[1:2]
> >=20
> > from pg_index as a
> >=20
> > This can result either in a segfault, a failed memory allocation or=
> > gibberish results.
>=20
> Hmm. int2vectorout expects the int2vector to have a single dimension,=
> but array_get_slice() returns a zero-dimension array if the result is=
empty.
>=20
> I don't think it's safe to allow slicing int2vectors (nor oidvectors)=
.
> It seems all too likely that the result violates the limitations of
> int2vector. In addition to that segfault, the array returned is 1-bas=
ed,
> not 0-based as we assume for int2vectors. One consequence of that is
> that if you COPY the value out in binary format and try to read it ba=
ck,
> you'll get an error.
>=20
> So I think we should just not allow slicing oidvectors, and throw an
> error. You can cast from int2vector to int2[], and slice and dice tha=
t
> as much as you want, so it's not a big loss in functionality. Another=
> solution would to provide a specialized slice-function for int2vector=
> and oidvector, but it's probably not worth the effort.
>=20
> Thanks for the report!
>=20
> - Heikki
Are the differences between int2vector and a regular array documented s=
omewhere=20
? What is the purpose of using this datatype instead of int2[] ?=20
On a sidenote, I would probably never have stumbled upon this bug if it=
was=20
clear that an int2vector was 0 indexed.=20
--=20
Ronan Dunklau
http://dalibo.com - http://dalibo.org
