Re: [HACKERS] ecpg long int problem on alpha + fix
Michael Meskes wrote: On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote: we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we have HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no Sure since that means your long int and not your long long int is 64 bits. code is included for long ints and typename calls *abort*. I put in a few lines that check for HAVE_LONG_INT_64 and seem to generate the right Why is this needed? What you do is use "long long" as variable type for 64 bits integer. But on the alpha you do not need "long long", just use "long int" instead. Or did I misunderstand something? OK, I see. Problem is that without the fix ecpg aborts when writing to a table with an int8 column using valid code. long int long long long long int all exist on alpha and are all 64 bits, but HAVE_LONG_LONG_INT_64 is not defined, so ecpg cannot handle ECPGt_long_long types. It is not clear to me what the best thing is to fix here -- possibly configure needs to set HAVE_LONG_LONG_INT_64 (which solves the problem on alpha as well), but I do not know what the consequences of that are. Cheers, Adriaan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg long int problem on alpha + fix
Michael Meskes wrote: On Wed, Apr 04, 2001 at 03:35:34PM +0300, Adriaan Joubert wrote: OK, I see. Problem is that without the fix ecpg aborts when writing to a table with an int8 column using valid code. Sorry, I still don't seem to understand that. Data between ecpg and the backend is tranfered in ascii only. What exactly happens? This has nothing to do with the backend. ecpg itself core-dumps after calling abort() at the end of the switch statement in typename.c, when processing a .pgc file. As people complained to me about ecpg core-dumping I tried to find out why and then found that it called the abort() at the end of this switch ;-) I have not looked at ecpg in any detail, but I expect that the types in typename.c are derived from the host variables in some way. If we have an int8 column in a table, we need to use a 64 bit type, i.e. a 'long long', and as HAVE_LONG_LONG_INT_64 is not true, no such type is compiled into the switch. As HAVE_LONG_INT_64 is defined on alpha, my fix fixes this for alpha, and any other platform where HAVE_LONG_INT_64 is defined but not HAVE_LONG_LONG_INT_64. From Tom's mail I gather that it is not an option to define HAVE_LONG_LONG_INT_64 on alpha, so I think this patch, or something similar, is necessary. Apologies for not being clear enough initially. Cheers, Adriaan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ecpg long int problem on alpha + fix
Could you please try to just remove the cpp flag? Also I wonder why you are using "long long int" instead of just "long int" in your C program. Well that is the people who complained to you. Yes, dropping the CPP flags solves the problem for us. I assume all platforms have long long now? We used long long as this seems to be pretty consistently 64 bits on different platforms, and our code runs on Tru64, PC linux and openBSD. It also agrees with the CORBA type naming for 64 bit ints, so it makes the type naming more consistent. Thanks, Adriaan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] ecpg long int problem on alpha + fix
Hi,
we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
have
HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
code is included for long ints and typename calls *abort*. I put in a
few lines that check for HAVE_LONG_INT_64 and seem to generate the right
code. I've got a new version of typename.c attached. It would be good if
Michael could review and get this into 7.1.
Cheers,
Adriaan
#include "config.h"
#include stdlib.h
#include "ecpgtype.h"
#include "ecpglib.h"
#include "extern.h"
#include "sql3types.h"
#include "pg_type.h"
/*
* This function is used to generate the correct type names.
*/
const char *
ECPGtype_name(enum ECPGttype typ)
{
switch (typ)
{
case ECPGt_char:
return "char";
case ECPGt_unsigned_char:
return "unsigned char";
case ECPGt_short:
return "short";
case ECPGt_unsigned_short:
return "unsigned short";
case ECPGt_int:
return "int";
case ECPGt_unsigned_int:
return "unsigned int";
case ECPGt_long:
return "long";
case ECPGt_unsigned_long:
return "unsigned long";
#if defined(HAVE_LONG_LONG_INT_64)
case ECPGt_long_long:
return "long long";
case ECPGt_unsigned_long_long:
return "unsigned long long";
#elif defined(HAVE_LONG_INT_64)
case ECPGt_long_long:
return "long int";
case ECPGt_unsigned_long_long:
return "unsigned long int";
#endif /* HAVE_LONG_LONG_INT_64 */
case ECPGt_float:
return "float";
case ECPGt_double:
return "double";
case ECPGt_bool:
return "bool";
case ECPGt_varchar:
return "varchar";
case ECPGt_char_variable:
return "char";
default:
abort();
}
return NULL;
}
unsigned int
ECPGDynamicType(Oid type)
{
switch (type)
{
case BOOLOID:return SQL3_BOOLEAN; /* bool */
case INT2OID:
return SQL3_SMALLINT; /* int2 */
case INT4OID:
return SQL3_INTEGER;/* int4 */
case TEXTOID:
return SQL3_CHARACTER; /* text */
case FLOAT4OID:
return SQL3_REAL; /* float4 */
case FLOAT8OID:
return SQL3_DOUBLE_PRECISION; /* float8 */
case BPCHAROID:
return SQL3_CHARACTER; /* bpchar */
case VARCHAROID:
return SQL3_CHARACTER_VARYING; /* varchar */
case DATEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* date */
case TIMEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* time */
case TIMESTAMPOID:
return SQL3_DATE_TIME_TIMESTAMP; /* datetime */
case NUMERICOID:
return SQL3_NUMERIC;/* numeric */
default:
return -type;
}
}
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Final call for platform testing
Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner We ran these regression tests with both native cc and gcc -- worth mentioning that both work. Adriaan ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Bug in user-defined types?
Hi, In response to comments made here, I have been rewriting the unsigned types as externally loadable. Using the same routines that worked fine when linked statically into the backend gives me core-dumps only. Creating only a single uint2 type with I/O routines, I get test=# create table u2 ( u uint2); CREATE test=# insert into u2 values (12::uint2); pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. Running this under gdb (I tried this on alpha as well) backend insert into u2 values (12::uint2); (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40115573 in memcpy () from /lib/libc.so.6 (gdb) where #0 0x40115573 in memcpy () from /lib/libc.so.6 #1 0x80cfb92 in _copyConst () #2 0x80d25d9 in copyObject () #3 0x80ebad9 in expression_tree_mutator () #4 0x80eb407 in eval_const_expressions_mutator () #5 0x80ebe42 in expression_tree_mutator () #6 0x80eb407 in eval_const_expressions_mutator () #7 0x80ebdf2 in expression_tree_mutator () #8 0x80eb407 in eval_const_expressions_mutator () #9 0x80eaf87 in eval_const_expressions () #10 0x80e6d2a in preprocess_expression () #11 0x80e6751 in subquery_planner () #12 0x80e66c0 in planner () #13 0x81036e7 in pg_plan_query () #14 0x81038d9 in pg_exec_query_string () #15 0x81049d4 in PostgresMain () #16 0x80ce884 in main () #17 0x400d8a42 in __libc_start_main () from /lib/libc.so.6 (gdb) It never seems to get to my code. So either I've defined something incorrectly or there is a bug. I'd appreciate it if somebody more knowledgable than I could have a look at it. I've included a tar with the definitions. BTW it may be good to update the complex example to the new C-calling interface, as there is no example of creating a type with the new calling interface. Cheers, Adriaan utest.tar.gz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bug in user-defined types?
Tom Lane wrote: Seems unlikely that that code could have worked either way, since you forgot to mark type uint2 as PASSEDBYVALUE... Aargh! Thanks! Yes, when implementing it in the backend, that was just a field to fill in, so I did it there. All seems well now. One ends up with a vast number of combinations of types combinations for different operators. As C takes care of the conversions, I wrote a 30-line perl script to generate me nearly 1600 lines of C for all the type combinations (+ ~1700 lines of sql to define the functions/operators). I cannot help feeling that that is not the right way: if it can be done in a few lines of perl and relies on C cross-type operations underneath anyway, it seems wrong to have to generate all this code. The problem is that there is not a clean hierarchy of SQL types, but for many cases one could either convert the operands to int4 or float8 and then numeric(?) and then convert back. At least the conversion operators check for overflow, which is better than the current situation. And precision wise it cannot be much worse: after all, large integer constants already end up as floats. Is the SQL standard pedantic about this? BTW I could not find the discussion on entry-points to shared libraries that Thomas mentioned. I've got some rushed dead-lines at the moment, so I will not be able to look at anything for the next 3-4 weeks though. Adriaan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Unsigned int functions
Bruce Momjian wrote: Adriaan Joubert [EMAIL PROTECTED] writes: Question is: should I add these functions? Are we looking at too much bloat, i.e. should I replace the (uint2,uint4) combinations with (int4,uint2) and (int4,uint4)? Lots of combinations are possible, but I do not have a good feel for the trade-offs. My guess is that we ought to avoid bloating the system with cross-datatype functions. I know there are some already for int2*int4 and so forth, but I'd like to see those go away in favor of a smarter type promotion scheme --- ie, the parser should be able to figure out that it ought to do int2_var * uint4_var as uint4_mul(uint4(int2_var), uint4_var) A cross-datatype function ought to exist only if it can usefully do something different from an implicit promotion. A larger question is whether unsigned types really add much to the system vs. the bloat. We already have unsigned int4 as oid. Also, unsigned doubles the space of the type, but if a value doesn't fit in 32k, what are the odds it will fit in 64k. I am not sure unsigned optimzations for space really are significant in SQL. A fair question. As I said, I only implemented them to simplify porting applications between database systems. Personally I think it is good to support types that make porting easier. On the other hand the arguments about bloat are strong. It seems to me that all cross-datatype functions should be removed, to reduce the number of functions for the unsigned data types to a minimum. Would this be a reasonable compromise? If general opinion is that unsigned types should not be part of postgres, I'll have to look at turning them into a contrib type. Please let me know. Cheers, Adriaan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] ecpg bug and patch
Hi, I've been doing some tests with writing int8 to the database using ecpg. This does not work if the long long variable is in a structure, as it is not recognised as a simple type. The patch is attached, but is not very satisfactory. Moving the definition of ECPGt_long_long, ECPGt_unsigned_long_long up to before ECPGt_varchar causes the resulting application to crash, as it finds an ECPGt_union, where it should haven found an ECPGt_EOIT (I think), and I could not figure out where the static offset comes from. Another problem with ecpg is that it dies on the alpha for long long variables unless #define HAVE_LONG_LONG_INT_64 is set in config.h. It is not set by default. Without fixing these int8 values cannot be written to the database. Regards, Adriaan diff -Naur postgresql-7.1RC1/src/interfaces/ecpg/include/ecpgtype.h postgresql-7.1RC1.orig/src/interfaces/ecpg/include/ecpgtype.h --- postgresql-7.1RC1/src/interfaces/ecpg/include/ecpgtype.hWed Mar 28 12:16:44 2001 +++ postgresql-7.1RC1.orig/src/interfaces/ecpg/include/ecpgtype.h Sun Jan 7 +04:03:39 2001 @@ -70,8 +70,7 @@ ECPGd_EODT /* End of descriptor types. */ }; -#define IS_SIMPLE_TYPE(type) ((type) = ECPGt_char (type) = ECPGt_varchar2 | -| (type)=ECPGt_long_long) +#define IS_SIMPLE_TYPE(type) ((type) = ECPGt_char (type) = ECPGt_varchar2) #ifdef __cplusplus } ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ecpg bug and patch
Ooops, patch was the wrong way round. Here is a better one. Sorry, Adriaan diff -Naur postgresql-7.1RC1.orig/src/interfaces/ecpg/include/ecpgtype.h postgresql-7.1RC1/src/interfaces/ecpg/include/ecpgtype.h --- postgresql-7.1RC1.orig/src/interfaces/ecpg/include/ecpgtype.h Sun Jan 7 04:03:39 2001 +++ postgresql-7.1RC1/src/interfaces/ecpg/include/ecpgtype.hWed Mar 28 12:36:05 +2001 @@ -70,7 +70,7 @@ ECPGd_EODT /* End of descriptor types. */ }; -#define IS_SIMPLE_TYPE(type) ((type) = ECPGt_char (type) = ECPGt_varchar2) +#define IS_SIMPLE_TYPE(type) ((type) = ECPGt_char (type) = ECPGt_varchar2 || +(type)=ECPGt_long_long) #ifdef __cplusplus } ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Unsigned ints (Help)
Uggh, this needs some help. I've got the problem that I can insert a value bigger than MAXINT into an int8 column, but when I try to do the same for a uint4 column, the parser coerces it into an int4, as in: test=# insert into tint8 values (3043140617); INSERT 30254 1 test=# insert into tuint4 values (3043140617); ERROR: Attribute 'a' is of type 'uint4' but expression is of type 'float8' You will need to rewrite or cast the expression test=# insert into tuint4 values (3043140617::uint4); INSERT 30255 1 Apparently this happens in parse_target.c, from where it calls CoerceTargetExpr from where it calls routines in parse_coerce.c. At this point I decided that somewhere in the definition of the type there must be a way of specifying how values can be transformed. Can anybody explain to me what I need to change to make this work? Without this ecpg cannot work with unsigned ints, so explicit casting is not an option. Cheers! Adriaan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Unsigned ints
Hi, I know I'm a bit early to submit stuff for 7.2, but attached is a patch (agains 7.1RC1) to add uint2 and uint4 as new types. I haven't put in all the possible combinations of signed and unsigned ints as arguments to operators -- I was going insane just doing it for all combinations of uint2 and uint4. If anything is missing, please let me know and I'd appreciate it if somebody could do some sanity checking on the patch, as this is the first time I've actually inserted a new type into the catalog. Also, some other databases (Compaq Himalaya) use SMALLINT UNSIGNED INTEGER UNSIGNED for these types. Dunno whether a type consisting of 2 words is going to break the parser completely. If there are any problems with the patch, please let me know as well -- not sure I've built it in the correct way. Regards, Adriaan patch.gz ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Call for platforms
Two more for the list (not a single regression test failing, which is a first on Alpha!) Tru64 4.0G Alpha cc-v6.3-129 7.1 2001-03-28 Tru64 4.0G Alpha gcc-2.95.1 7.1 2001-03-28 I updated the regression test database as well. Adriaan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: int8 bug on Alpha
This is a portability bug, no question. But I'd expect it to fail like that on all Alpha-based platforms. Adriaan, when you say it works on Linux, are you talking about Linux/Alpha or some other hardware? No, PC Linux. I run a database on my laptop as well. Adriaan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] int8 bug on Alpha
Hi, int8 is not handled correctly on Alpha. Inserting 2^63-1, 2^63-2 and 2^61 into create table lint (i int8); gives test=# select * from lint; i -1 -2 0 (3 rows) On linux it gives the correct values: test=# select * from lint; i - 9223372036854775807 9223372036854775806 2305843009213693952 (3 rows) This is postgres 7.1b4, compiled with native cc on Tru64 4.0G. I seem to recall running the regression tests, so perhaps this is not checked? (just looked at int8.sql, and it is not checked.) I'm swamped, so cannot look at it right now. If nobody else can look at it, I will get back to it in about a fortnight. Adriaan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: int8 bug on Alpha
Thomas Lockhart wrote:
int8 is not handled correctly on Alpha. Inserting 2^63-1, 2^63-2 and
2^61...
How are you doing the inserts? If you aren't coercing the "2" to be an
int8, then (afaik) the math will be done in int4, then upconverted. So,
can you confirm that your inserts look like:
insert into lint values ('9223372036854775807');
OK, that was it. I inserted without quotes. If I insert the quotes it
works. So why does it work correctly on linux without quotes?
and
insert into lint values ('9223372036854775807'::int8);
works, but
insert into lint values (9223372036854775807::int8);
doesn't. I guess in the second case it converts it to an int4 and then
recasts to an int8?
Cheers,
Adriaan
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: int8 bug on Alpha
Anyway, either strtol() thinks it *should* be able to read a 64 bit
integer, or your machine is silently overflowing. I used to have a bunch
of these boxes, and I recall spending quite a bit of time discovering
that Alphas have some explicit flags which can be set at compile time
which affect run-time detection of floating point and (perhaps) integer
overflow behavior.
Can you check these possibilities? I'd look at strtol() first, then the
overflow/underflow flags second...
Hmm, I wrote a trivial programme parsing long ints and get the following
#include errno.h
main (int argc, char *argv[]) {
long int a = strtol(argv[1], (char **) 0, 10);
printf("input='%s' ld=%ld (errno %d)\n",argv[1],a,errno);
}
emily:~/Tmp/C++$ a.out 9223372036854775807
input='9223372036854775807' ld=9223372036854775807 (errno 0)
emily:~/Tmp/C++$ a.out 9223372036854775808
input='9223372036854775808' ld=9223372036854775807 (errno 34)
emily:~/Tmp/C++$ a.out 9223372036854775806
input='9223372036854775806' ld=9223372036854775806 (errno 0)
emily:~/Tmp/C++$ a.out -9223372036854775808
input='-9223372036854775808' ld=-9223372036854775808 (errno 0)
so that seems to work correctly. And I compiled with the same compiler
flags with which postgres was compiled. Apparently long is defined as
'long long int' on alpha, and I tried it with that and it works as well.
I'll have to debug this properly, but first I need to get Friday out of
the way ;-)
Adriaan
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Call for platforms
Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry We've got 7.0.3 and 7.1b4 running on Compaq Tru64 4.0G Alpha Will do the regression test once RC1 is out. Adriaan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Alpha tas() patch
Hi, I missed the beginning of this thread. Are you doing this for Tru64 or for Linux? For Tru64 there are macros in /usr/include/alpha/builtins.h which do the job. Doing this in assembler is totally non-trivial, as most versions are only liable to work on single-processor machines and not on SMP boxes (the problem with the previous linux TAS, I believe). Adriaan
Re: [HACKERS] (7.1) BIT datatype
Christopher Kings-Lynne wrote:
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
B'[bit...]'[{separator...'[bit...]'}...]
X'[hexdigit...]'[{separator...'[hexdigit...]'}...]
(Cannan and Otten: SQL - The Standard Handbook, p.38)
but the hexadeximal form is not accepted.
As Peter noted: the standard does not say whether X'..' should be a
blob, a bit or a varbit type. Converting it into an integer seems to me
to be the least reasonable solution, albeit the historical one, as
larger bitmasks will not fit. With TOAST the bit type can contain quite
large bit strings, so a case could be made for converting to bit
(especially as the blob implementation has reputedly got some problems).
I have been using the BIT and VARBIT types in Postgres 7.0.3 (undocumented I
believe), and I note that the _input_ format is as follows:
update blah set flags='b101001'; -- Binary
update blah set flags='xff45'; -- Hex
Yes, that was done due to limitations in the parser. These have been
fixed and this format should not be used any longer.
But the _output_ format (for varbit) is always:
B'1010110'
The SQL standard says nothing about the output of the BIT datatypes. The
C-routines to interpret both the B'..' and X'..' formats, as well as
output routines to generate both are implemented and included. The
problem is that a default had to be chosen, and the B'..' format seemed
more useful for people using small bit masks.
I don't know whether a function was defined to return an X'..' string of
a bit mask. I don't have one of the more recent Postgres snapshots down
at the moment. Peter E. may know, as he did all the integration.
An alternative may be to add a 'SET variable' to psql to govern the
output format, but there seem to be too many of those already.
Adriaan
Re: [HACKERS] RFC C++ Interface
Randy Jonasz wrote: I appreciate your comments and would like to respond to your concerns. The API I sketched in my earlier e-mail is borrowed heavily from Rogue Wave's dbtools.h++ library. I think it can be a very clean and elegant way of accessing a database. Yes, this looks neat. At least it is an API design that has been properly tested. We've been thinking along the same lines, and were thinking of faking up a roguewave type API for postgres. One thing I would like to see, which we have built into our own, primitive, C++ interface, is support for binary data retrieval. For some applications the savings are huge. I haven't thought very hard about how to do this: we do it by having a perl script generate structures from the table definitions at compile time, which works well in our case, but is not necessarily suitable for a library. Code to copy the data into these structures is similarly generated. Not sure whether roguewave have a better solution. Good luck with it. Adriaan
Re: [HACKERS] COPY BINARY is broken...
Hi, I would very much like some way of writing binary data to a database. Copy binary recently broke on me after upgrading to 7.0. I have large simulation codes and writing lots of floats to the database by converting them to text first is 1) a real pain, 2) slow and 3) can lead to unexpected loss in precision. I think binary writes would actually be solved better and safer through some type of CORBA interface, but previous discussions seemed to indicate that that is even more of a pain than fixing the current binary interface. So I agree that the current version is a problem, but I do think something needs to be put in place. Not everybody only writes a few numbers from a web page into the database -- some have masses of data to dump into a database. For all I care it doesn't even have to look like SQL, but can be purely accessible through libpq. Adriaan
Re: [HACKERS] Re: BIT/BIT VARYING status
Peter,
I've looked at the current implementation of the bit types and still
have some doubts concerning the following issues:
1. Constants. The current behaviour just seems somewhat strange, and I
have no idea where to fix it.
test=# select B'1001';
?column?
--
X9
(1 row)
test=# select B'1001'::bit;
ERROR: Cannot cast this expression to type 'bit'
test=# select B'1001'::varbit;
ERROR: Cannot cast this expression to type 'varbit'
test=# select 'B1001'::varbit;
?column?
--
B1001
(1 row)
test=# select 'B1001'::bit;
?column?
--
X9
(1 row)
test=# select X'1001'::varbit;
ERROR: varbit_in: The bit string 4097 must start with B or X
test=# select 'X1001'::varbit;
?column?
---
B00010001
(1 row)
test=# select 'X1001'::bit;
?column?
--
X1001
(1 row)
test=# select X'1001'::bit;
ERROR: zpbit_in: The bit string 4097 must start with B or X
Also, I have two output routines, that have been renames to zpbit_out
and varbit_out. In fact, both will work just fine for bot bit and
varbit, but the first prints as hex and the second as a bit string.
Printing as hex is more compact, so good for long strings, but printing
as a bit string is much more intuitive. One solution would be to make
them both print to a bit string by default and define a function to
generate a hex string. Another would be to have this under control of a
variable. Most people who contacted me about bit strings seemed to want
to use them for flags, so I guess the default should be to print them as
a bit string.
More for my information, if a user does not know about varbit, how does
he cast to bit varying?
2. This is not a problem, more a question. There is no default way to
compare bit to varbit, as in
test=# select 'b10'::bit='b10'::varbit;
ERROR: Unable to identify an operator '=' for types 'bit' and 'varbit'
You will have to retype this query using an explicit cast
This may be a good thing, as the comparison does depend on the lenght of
the bit strings.
3. The ^ operator seems to attempt to coerce the arguments to float8?
select 'B110011'::bit ^ 'B011101'::bit;
ERROR: Function 'float8(bit)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
4. This is a policy question. When I use the bit shift operator, this
always shifts within the current string only. So if I do
select ('B010'::bit(6) 2)::varbit;
?column?
---
B000100
I get what I would expect. But if I have a bit varying(6) field (in a
table, this is just an example), I only get
select ('B010'::varbit 2)::varbit;
?column?
---
B000
which I find counter-intuitive. I have thus added 'zpshiftright' and
'varbitshiftright' functions. The second extends the bitstring to the
right, while the first is the old bitshiftright function. I find this
more intuitive at least.
Question is what a shift left function should do? Should I shorten the
string in the case of a shift left, to keep it symmetrical to shift
right? This seems a pure policy decision, as there are arguments for
both behaviours, although I am a great fan of symmetry. Let me know and
I can implement a separate function.
I have made a start on a file for regression tests, which I append with
the diffs for the varbit files. Please let me know what else is needed
and where I can help.
Thanks!
Adriaan
--
-- BIT types
--
--
-- Build tables for testing
--
CREATE TABLE ZPBIT_TABLE(b BIT(11));
INSERT INTO ZPBIT_TABLE VALUES ('B');
INSERT INTO ZPBIT_TABLE VALUES ('B0');
INSERT INTO ZPBIT_TABLE VALUES ('B010101');
INSERT INTO ZPBIT_TABLE VALUES ('B01010101010');
INSERT INTO ZPBIT_TABLE VALUES ('B010101010101');
INSERT INTO ZPBIT_TABLE VALUES ('X554');
INSERT INTO ZPBIT_TABLE VALUES ('X555');
SELECT * FROM ZPBIT_TABLE;
CREATE TABLE VARBIT_TABLE(v BIT VARYING(11));
INSERT INTO VARBIT_TABLE VALUES ('B');
INSERT INTO VARBIT_TABLE VALUES ('B0');
INSERT INTO VARBIT_TABLE VALUES ('B010101');
INSERT INTO VARBIT_TABLE VALUES ('B01010101010');
INSERT INTO VARBIT_TABLE VALUES ('B010101010101');
INSERT INTO VARBIT_TABLE VALUES ('X554');
INSERT INTO VARBIT_TABLE VALUES ('X555');
SELECT * FROM VARBIT_TABLE;
-- Delete from tables
DROP TABLE ZPBIT_TABLE;
CREATE TABLE ZPBIT_TABLE(b BIT(16));
INSERT INTO ZPBIT_TABLE VALUES ('B11011');
INSERT INTO ZPBIT_TABLE SELECT b1 FROM ZPBIT_TABLE;
INSERT INTO ZPBIT_TABLE SELECT b2 FROM ZPBIT_TABLE;
INSERT INTO ZPBIT_TABLE SELECT b4 FROM ZPBIT_TABLE;
INSERT INTO ZPBIT_TABLE SELECT b8 FROM ZPBIT_TABLE;
SELECT POSITION('B1101'::bit IN b) as pos,
POSITION('B11011'::bit IN b) as pos,
b
FROM ZPBIT_TABLE ;
DROP TABLE VARBIT_TABLE;
CREATE TABLE VARBIT_TABLE(v BIT VARYING(19));
INSERT INTO VARBIT_TABLE VALUES ('B11011');
INSERT INTO VARBIT_TABLE SELECT v1 FROM VARBIT_TABLE;
INSERT INTO VARBIT_TABLE SELECT v2 FROM VARBIT_TABLE;
INSERT INTO VARBIT_TABLE SELECT
Re: [HACKERS] Re: BIT/BIT VARYING status
Peter Eisentraut wrote: Adriaan Joubert writes: 2. We don't handle bit string and hex string literals correctly; the scanner converts them into integers which seems quite at variance with the spec's semantics. This is still a problem that needs to be fixed. I have gotten the B'1001'-style syntax to work, but the zpbit_in function rejects the input. You need to change the *_in functions to accept input in the form of a string of only 1's and 0's. Also, the output functions should print 1's and 0's. I'm somewhat confused about the hex strings; according to the standard they might also be a BLOB literal. I'd say we get the binary version working first, and then wonder about this. Peter, I think it is a problem if the B or X are dropped from the input, as that is the only way to determine whether it is a binary or hex string. Isn't it possible to just remove the quotes, or even do nothing? The current code expects a string of the form Bx or Xy. If the quotes are left in, I can easily modify the code, but guessing whether the string 1001 is hex or binary is an issue, and I seem to recall that the SQL standard requires both to be valid input. Also, on output, shouldn't we poduce B'' and X'y' to conform with the input strings? Adriaan
Re: [HACKERS] Strange error message
Tom Lane wrote: Adriaan Joubert [EMAIL PROTECTED] writes: we've suddenly started getting this error message out of postgres (7.0.2). Does anybody know where it comes from? ERROR: UNLockBuffer: buffer 0 is not locked Evidently something is passing an invalid buffer number to LockBuffer in src/backend/storage/buffer/bufmgr.c. (0 is InvalidBuffer, but LockBuffer won't notice that unless you compiled with asserts enabled.) Whatever the bug is, it's not directly LockBuffer's fault. Right, I'vebuilt a new database and everything seemed fine for a while and now I've got this message back. It is due to the index on one of our tables getting messed up - at least, if we drop and recreate the index everything is fine. What should I do to track down what is happening? Compile with asserts, or run with specific logging? Any advice appreciated! Adriaan
