On Thursday 11 September 2003 10:40, Andreas Pflug wrote: > Richard Huxton wrote: > >On Thursday 11 September 2003 09:33, Andreas Pflug wrote: > >>*NO PARSING* > >>The script must be stuffable into PQexec in total, backend does the rest. > >> > >>Again: not psql, but sql language itself must provide this. > >> > >>No out-of-band, because this would require splitting the script in > >> pieces. > > > >What's wrong with re-using the COPY FROM format? > > I must be writing a completely ununderstandable english, sorry for that. > > *NO PARSING*, I don't know how to express this differently.
I think it's my problem - I thought COPY mytable FROM source_file *was* something handled by the SQL parser in the backend, i.e. you could use it via psql / DBI / jdbc / whatever. As it turns out, if the source file is an actual file (/tmp/foo.sql) then you can, but not if it's "stdin". Presumably, there's some magic going on if you use psql/pg_restore (NOTE-should this be mentioned in the docs). > What I'm saying all the time that a single sql script file containing a > huge number of statements including function creation must be executable > without parsing it, splitting it into parts and stuffing the data into > different functions. > > When creating a new instance of a database for an app, I don't create > each object one by one interactively, but use a script for this. To > create the script, I certainly won't use psql and some arbitrary editor, > but a frontend allowing for editing and executing that script. I agree completely with you - a single file containing statements that I can run into PG via any convenient connection, not something that works one way and not another. -- Richard Huxton Archonet Ltd ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match