Patch: Allow substring/replace() to get/set bit values
Hi all,
attached a patch that adds the following functions for bit string:
- overlay
- get_bit
- set_bit
Some info:
1) overlay is implemented as calls to substring; given the different way substring behaves when used with strings vs bit strings:
test=# SELECT substring(B'1111000000000001' from 1 for -1);
substring
------------------
1111000000000001
(1 row)
test=# SELECT substring('1111000000000001' from 1 for -1);
ERROR: negative substring length not allowed
I don't think that this overlay implementation is what we want?
Example:
test=# SELECT overlay(B'1111' placing B'01' from 1 for 2);
overlay
---------
0111
(1 row)
(looks ok)
test=# SELECT overlay(B'1111' placing B'01' from 0 for 2);
overlay
-----------
111101111
(1 row)
????
This happens because substring(bit, pos, -1) means substring(bit, pos, length(bit string)),
and < -1 values for bit substring parameters are allowed: is this a bug in bit substring???
2) I tried implementing bit_get and bit_set as calls to overlay/substring:
DATA(insert OID = 3032 ( get_bit PGNSP PGUID 14 1 0 0 f f f t f i 2 0 23 "1560 23" _null_ _null_ _null_ _null_ "select (pg_catalog.substring($1, $2, 1))::int4" _null_ _null_ _null_ ));
DESCR("get bit");
DATA(insert OID = 3033 ( set_bit PGNSP PGUID 14 1 0 0 f f f t f i 3 0 1560 "1560 23 23" _null_ _null_ _null_ _null_ "select pg_catalog.overlay($1, $3::bit, $2, 1)" _null_ _null_ _null_ ));
DESCR("set bit");
but this doesn't give any check on the values provided:
that the bit looked for is in fact in the right range, and that the bit in set_bit is in fact a bit
(I don't like the idea of writing "select set_bit(B'01010111', B'1')" instead of
"select set_bit(B'01010111', 1)" ).
So I coded them in proper C internal functions.
Leonardo
Attachments:
patch_bit.patchapplication/octet-stream; name=patch_bit.patchDownload+142-7
On Thu, Jan 7, 2010 at 7:02 AM, Leonardo F <m_lists@yahoo.it> wrote:
attached a patch that adds the following functions for bit string:
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
The next CommitFest starts January 15th.
...Robert
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
Ok; but what about what I said about the difference between bit/string substring?
That affects overlay behaviour for bit...
I've even got
"ERROR: invalid memory alloc request size 4244635647"
with:
SELECT substring(B'1111000000000001' from 5 for -2);
(this is 8.4.2, windows version, not modified...)
test=# SELECT substring(B'1111000000000001' from 1 for -1);
substring
------------------
1111000000000001
(1 row)
test=# SELECT substring('1111000000000001' from 1 for -1);
ERROR: negative substring length not allowed
On Thu, Jan 7, 2010 at 11:05 AM, Leonardo F <m_lists@yahoo.it> wrote:
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
Ok; but what about what I said about the difference between bit/string substring?
That affects overlay behaviour for bit...I've even got
"ERROR: invalid memory alloc request size 4244635647"
with:
SELECT substring(B'1111000000000001' from 5 for -2);
(this is 8.4.2, windows version, not modified...)
test=# SELECT substring(B'1111000000000001' from 1 for -1);
substring
------------------
1111000000000001
(1 row)test=# SELECT substring('1111000000000001' from 1 for -1);
ERROR: negative substring length not allowed
I haven't tried to reproduce it, but that sounds like a bug.
....Robert
Leonardo F <m_lists@yahoo.it> writes:
I've even got
"ERROR: invalid memory alloc request size 4244635647"
with:
SELECT substring(B'1111000000000001' from 5 for -2);
Hm, yeah, somebody was sloppy about exposing the three-argument
form of varbit substring and using -1 to represent the two-argument
form.
What we can do in the back branches is make the code treat any
negative value as meaning two-arg form. To throw an error we'd
need to refactor the pg_proc representation ...
regards, tom lane
What we can do in the back branches is make the code treat any
negative value as meaning two-arg form. To throw an error we'd
need to refactor the pg_proc representation ...
I was going to fix that myself, but I think it has just been done.
How can I keep up with "who's doing what"?
Leonardo F wrote:
What we can do in the back branches is make the code treat any
negative value as meaning two-arg form. To throw an error we'd
need to refactor the pg_proc representation ...I was going to fix that myself, but I think it has just been done.
How can I keep up with "who's doing what"?
Read this list and pgsql-committers.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Leonardo F wrote:
How can I keep up with "who's doing what"?
Read this list and pgsql-committers.
Or subscribe to the RSS feed from:
http://git.postgresql.org/gitweb?p=postgresql.git;a=summary
--
dim