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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
25 matches
Mail list logo
