| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, 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 21:14:30 |
| Message-ID: | 18772.967497270@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> 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 ...)
Seems like a reasonable idea, although I'd recommend sticking to the
convention that \. on a line means EOD, to avoid having to hack the
client-side libraries. As long as you leave that alone, libpq,
libpgtcl, etc etc should be transparent to the copy data format.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris | 2000-08-29 00:07:39 | Re: Re: UNION JOIN vs UNION SELECT |
| Previous Message | Tom Lane | 2000-08-28 21:05:10 | Re: SQL COPY syntax extension (was: Performance on inserts) |