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
Tom Lane writes:
Pete Forman [EMAIL PROTECTED] writes:
The regression test is failing early on, during initdb. The core
file indicates that there is a SIGBUS. Hopefully the bugs fixed
as a result of the "More bogus alignment assumptions" thread will
sort things out.
Sure
On 3/27/01 8:05 AM, "Tom Lane" [EMAIL PROTECTED] wrote:
Alexander Klimov [EMAIL PROTECTED] writes:
Yes, it was really just incidence -- I try again, and 15 of 15 `make
check' passed with TCP sockets, but only 3 of 15 passed with UNIX
sockets. So, final decision is `Unix sockets are not
Pete Forman writes:
I've registered the result via the web form though the report is
not accurate. Can somebody update the Remarks or Version field to
indicate that I was using a snapshot rather than RC1 OOTB.
Further to that request, please ignore/delete the existing Remarks.
I have
In any case, a unified or context diff against the 7.1beta4 spec would
be useful.
OK, here is a context diff of the spec file (note only two lines
changed). This addresses the "-fno-fast-math" problem on Mandrake (at
least 7.2 and earlier), and the "disappearing Pg.bs file" problem on
same.
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
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.
At 3/28/2001 09:52 AM, Joel Burton wrote:
On Wed, 28 Mar 2001, Bruce Momjian wrote:
Actually,
This reminds me of something I have been meaning to ask. All the new
performance features are cool, but what I really need are all the ALTER
TABLE ... functions implemented. In 7.0.x
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Hm, you're right:
http://www.postgresql.org/devel-corner/docs/postgres/xact-read-committed.html
"Read Committed is the default isolation level in Postgres. When
a transaction runs on this isolation level, a SELECT query sees only
data committed
Tom Lane writes:
It seems that in pre-7.0 Postgres, this works:
create table one(id int default 1, descr text);
create table two(id int default 2, tag text) inherits (one);
with the net effect that table "two" has just one "id" column with
default value 2.
Although the liberty to do
On Wed, Mar 28, 2001 at 06:48:27PM -0500, Tom Lane allegedly wrote:
Mathijs Brands [EMAIL PROTECTED] writes:
PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked.
Hm. But 7.1 postgres backends fail to change their ps display?
Does sendmail change its ps display on your machine?
Mathijs Brands [EMAIL PROTECTED] writes:
mathijs297 0.1 0.2 6120 3352 pts/1S 01:59:18 0:00
/opt/pgsql/bin/./postgres mathijs localhost template1 idle
The interesting point about this is that the 7.0.3-on-2.7 installation
*is* managing to change its PS display. So either Solaris 2.8
Mathijs Brands [EMAIL PROTECTED] writes:
PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked.
Hm. But 7.1 postgres backends fail to change their ps display?
Does sendmail change its ps display on your machine?
Seems we could easily use the sendmail display to populate the ps
display
Larry Rosenman [EMAIL PROTECTED] writes:
FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
including UnixWare. The UnixWare code will need /dev/kmem permission to
change it's stuff, so I don't know whether we want to do this or not, but
if people are looking at
Bruce Momjian writes:
Can someone confirm that 'ps' status display doesn't work on Solaris,
You may need to use /usr/ucb/ps. Last I checked there was no way to
change the display of /usr/bin/ps.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
At 12:27 AM 3/28/01 -0500, Tom Lane wrote:
That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?
I don't think this solution would be valid on many other platforms. It forces the
structure to not be padded,
Bruce Momjian writes:
Can someone confirm that 'ps' status display doesn't work on Solaris,
You may need to use /usr/ucb/ps. Last I checked there was no way to
change the display of /usr/bin/ps.
I can do that, but I am told that /usr/ucb/ps does not allow me to
restrict the display to
I just had a discussion with a user who doesn't want to update from
6.4.something to 7.0.* because 7.0 broke a feature he likes, namely
the ability to change the default value of a column inherited from
a parent table. It seems that in pre-7.0 Postgres, this works:
create table one(id int
19 matches
Mail list logo
