Re: octave-database - data entry into database table

[richard]

On Sun, Feb 10, 2013 at 11:24:19PM +0100, Olaf Till wrote:
> On Sun, Feb 10, 2013 at 08:13:09PM +0000, richard wrote:
> > Hi all, 
> > 
> > Getting data from a table seems simple when compared with
> > output of data from octave into a table. As a first attempt 
> > something like this might work except postgres wants 
> > newlines and octave dislikes backslashes. 
> > 
> > > sql("copy rome001 (year, l_pay, legion_pay, legions, Army_pay) from 
> > > stdin;  3 4 5 6 7 \."); 
> > 
> > Has anyone used something similar to this successfully? 
> 
> I'm fairly sure that neither this nor anything similar, nor the 'copy'
> command at all, can have worked with the old database package which
> you refer to.
> 
> There is a new database package (version 2.0.0) with working
> postgresql support, but different commands. 
I did install the new version. I seem to have permission problems 
with that (or something similar,) and I reinstalled the old version. 
I wanted to complete some work before I tried to find out what went wrong. 

FWIW the above code responds with 
error: postgres error: PGRES_FATAL_ERROR, ERROR:  syntax error at or near "3"   

That suggested to me that "copy" might work and I was thinking that 
either changing the default newline on postgres or octave might be 
a possible way of getting "copy" to work. 

> Converting data directly
> from Octave values into a table is supported for sql-commands except
> 'copy', with placeholders ($1, $2, ... see help of
> pq_exec_params). 
First, I need to get the new version installed correctly :-)
BTW, does the old version have to be stripped out completely? 

> For 'copy ... from stdin' there are some problems so
> this is currently only supported from files. You could use 'insert'
> statements as an alternative to 'copy ... from stdin'. If this is too
> slow, maybe combining with 'prepare' can help.
> 
Yes, "insert" works, and for this work, speed is not a problem. 
Where "big" data has to be moved, files are probably essential. 

Richard