From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Oliver Teuber <teuber(at)abyss(dot)devicen(dot)de>, Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL COPY syntax extension (was: Performance on inserts) |
Date: | 2000-08-28 18:20:27 |
Message-ID: | 39AAAD6B.DC27E0C6@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart wrote:
>
> > Could copy be extended to support a more SQL-friendly syntax. like
> > COPY tablename FROM VALUES(
> > (x1,y1,z1),
> > (x2,y2,z2),
> > (x3,y3,z3)
> > );
> > Extending the COPY command would probably be much easier than speeding up
> > INSERTS.
>
> That syntax is a lot like a real SQL9x INSERT. Supporting multiple rows
> for inserts is probably not that difficult; but since INSERT is used so
> much we would have to make sure we don't screw up something else. At the
> moment, expanding a line of SQL into multiple internal querytree nodes
> is a bit crufty but is possible.
What I actually had in mind was a more SQL-like syntax for copy, i.e. no
default arguments, all fields required etc. that would we easy to bolt
on
current copy machinery but still use 'SQL' syntax (no . or \. or \\. for
EOD,
NULL for NULL values, quotes around strings ...)
------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-08-28 18:29:17 | Re: SQL COPY syntax extension (was: Performance on inserts) |
Previous Message | Tom Lane | 2000-08-28 18:03:30 | Re: Re: UNION JOIN vs UNION SELECT |