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
Tom Lane wrote:
>
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > Yes, dropping the CPP flags solves the problem for us. I assume all
> > platforms have long long now?
>
> Surely you jest.
Yep, it was a rhetorical question.
I think we probably do need the CPP
> 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?
W
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 th
> 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 appropr
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 ri
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
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 tabl
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)
Hi,
I finally seem to have my unsigned int2/int4 types working correctly,
but will wait until 7.1 is out of the door, and test a bit more, before
resubmitting.
A question though:
I've put in functions (as copied from the int2/int4 implementation) that
implement operators for differentl
Hi,
I've got the weird behaviour in an ecpg programme that when I issue
EXEC SQL SET AUTOCOMMIT TO ON;
transactions behave as one would expect, i.e. I can use BEGIN
WORK/COMMIT/ROLLBACK, but when I set
EXEC SQL SET AUTOCOMMIT TO OFF;
every statement is wrapped in its own tra
Tom Lane wrote:
> See past discussions about appropriate handling of unlabeled numeric
> constants. This is a tricky area that needs a thoroughgoing rethink.
> If you go into it with only "fix uint4" in mind then you will almost
> certainly make things worse.
Gosh, you were certainly right there
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 va
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
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_lon
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
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)-
> 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
---
> 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 a
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 l
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
-
> 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 [
fdatasync() is available on Tru64 and according to the man-page behaves
as Tom expects. So it should be a win for us. What do other commercial
unixes say?
Adriaan
Main open item is the handling of hex strings: they are still converted
to integers by default. They could be BLOBs or bit strings, and the SQL
standard gives no hint, so it is not clear what the solution should be.
The only other complaint has been on the output of bit strings. I
believe the cur
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 no
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'[...]'[{...'[ > X'[...]'[{...'[ >
> > (Cannan and Otten: SQL - The Standard Handbook, p.38)
> >
> > but the hexadexim
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. A
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 unexpe
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)
te
Thanks Peter. I will download tomorrow when the new snapshot is
available. So how do we find out whether hex needs to be supported? I
see what you mean with ('1001' as bit), but shouldn't that be (B'1001'
as bit)? Certainly if hex values are allowed the first version is
ambiguous. I would have to
Peter Eisentraut wrote:
>
> Adriaan Joubert writes:
>
> > > 2. We don't handle and literals correctly;
> > > the scanner converts them into integers which seems quite at variance
> > > with the spec's semantics.
> >
> > This is still
Tom Lane wrote:
>
> I have made a first cut at completing integration of Adriaan Joubert's
> BIT code into the backend. There are a couple little things left to
> do (for example, scalarltsel doesn't know what to do with BIT values)
> as well as some not-so-little things:
>
> 1. SQL92 mentions
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
>
> Evident
Hi,
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
Any help appreciated,
Adriaan
34 matches
Mail list logo
