On Tue, May 4, 2010 at 10:08 AM, Erik Rijkers <e...@xs4all.nl> wrote:
> fwiw, results for all current postgres versions:
> [ only 9.0beta1 is different ]
It looks like the relevant commits are:
commit 822f2ac5a2ec7c6f10634f62a0b2dc6cc9929759
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Mon Jan 25 20:55:32 2010 +0000
Add get_bit/set_bit functions for bit strings, paralleling those for bytea,
and implement OVERLAY() for bit strings and bytea.
In passing also convert text OVERLAY() to a true built-in, instead of
relying on a SQL function.
Leonardo F, reviewed by Kevin Grittner
commit 75dea10196c31d98d98c0bafeeb576ae99c09b12
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Thu Jan 7 19:53:11 2010 +0000
Make bit/varbit substring() treat any negative length as meaning "all the re
of the string". The previous coding treated only -1 that way, and would
produce an invalid result value for other negative values.
We ought to fix it so that 2-parameter bit substring() is a different C
function and the 3-parameter form throws error for negative length, but
that takes a pg_proc change which is impractical in the back branches;
and in any case somebody might be relying on -1 working this way.
So just do this as a back-patchable fix.
I think the OP is probably running a version that doesn't include the
Jan 7 commit, which was effectively undone by the Jan 25 commit for
CVS HEAD. It looks like this was intentional based on spec behavior
of overlay(), but should we consider maintaining the historical
behavior instead?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
