copy binary from stdin; Why is it broken?
Hi,
For speed I had a programme (actually a CORBA server) that would
receive a lot of records, copy them into a binary record and copied them
into the database. As this is a CORBA server on the same machine as the
database, there are no endedness problems or anything like that. This
worked just great until the latest update: now I get 'COPY BINARY is not
supported to stdout or from stdin'. In the context of psql there may be
good reasons for this, but from a programme it works well, so why
disallow it? Now I've got to go and convert everything to a load of
printf's, which are then converted back into binary -- seems kind-of
silly. And I'm not comfortable with these types of conversions for
floats at all.
On a separate note: what would be really great for loading large amounts
of data into a database is if one could have a serial field that
updated anyway. Some databases give you the next serial value if you try
to insert null -- which seems reasonable in the context of a SERIAL,
which is NOT NULL. I can see that this may cause problems in the case of
fields that do a default nextval('sequence'), and which consequently can
be null, but the benefits would be large.
Often simulations or sensors (we have both) generate large streams of
binary data and a way of loading this data into the database rapidly is
very, very useful.
Adriaan
Hi everybody...
I need a clue...Maybe someone of you has something to suggest :)
I'm developing a server with mico and postgresql in c++... The access to
postgresql
is done using libpq, not via corba...The compiler I use is gcc-2.95-2
The operating systems are Linux and Solaris 2.7.
On Solaris I'm trying to use Purify 5.1 but it founds a memory segment
error
during mico initialization and my program dumps core. Then I've get out
mico and even Xerces (an XML parser) out of the server but then purify
complains about an error in a an fstream function, like:
IPR: Invalid pointer read
This is occurring while in:
ifstream::~ifstream() [fstream.cc:110]
{
return "w";
}
=> #endif
Configuration::loadConfig(const char*) [Configuration.o]
DSControl_impl::start() [ds_sds_nocorba_impl.o]
main [ds_sds_nocorba_main.o]
_start [crt1.o]
Reading 4 bytes from 0xff1927a4 between the heap and the stack.
I've been forced to use libpq from version 6.5.3 because if I link the
7.0.2
version in then I get an error from a function inside PostgreSQL setdb
The error is always the same: the program is accessing an area between the
heap and the stack......but just migrates around corba, ifstream,
postgres.....
Well... Before I go squashing my head on the wall again, dou you have an
idea on
how to get more info on this ??????????
I know this is a bit OT here, because I don't think postgres is really
involved in this,
simply I don't know what to do with this... Could it be simply a purify
problem ????
The system seems to work fine without it....(seems......)
Thanks for your patience....
Fabrizio
--
Fabrizio Sciarra ! Tel +39 050 545 111
Intecs sistemi spa ! Fax +39 050 545 200
via Gereschi 32-34, 56100 Pisa ITALY. ! fabrizio@pisa.intecs.it
-- My opinions are mine, not necessarly of my employers --
* Linux. The choice of a GNU generation
* Java Lobby Member * Ada community member.