Thread: 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
bitstrings:
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
Attachment
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