Re: Reg: SQL Query for Postgres 8.4.3
От | Robert Haas |
---|---|
Тема | Re: Reg: SQL Query for Postgres 8.4.3 |
Дата | |
Msg-id | AANLkTikNOq_iGd2DmQOttL7nZuBbwtpu8ZNdAO34NF9y@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reg: SQL Query for Postgres 8.4.3 ("Erik Rijkers" <er@xs4all.nl>) |
Ответы |
Re: Reg: SQL Query for Postgres 8.4.3
|
Список | pgsql-hackers |
On Tue, May 4, 2010 at 10:08 AM, Erik Rijkers <er@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 <tgl@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 stringsand 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 <tgl@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 treatedonly -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 errorfor negative length, but that takes a pg_proc change which is impractical in the back branches; and in any casesomebody 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
В списке pgsql-hackers по дате отправления: