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