| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Sergey Ten <sergey(at)sourcelabs(dot)com>, "'Christopher Kings-Lynne'" <chriskl(at)familyhealth(dot)com(dot)au>, jason(at)sourcelabs(dot)com |
| Subject: | Re: Escape handling in COPY, strings, psql |
| Date: | 2005-05-29 19:10:32 |
| Message-ID: | 12092.1117393832@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I do support gradually phasing out backslash escapes in standard string
> literals in the interest of portability. Most of the current escape
> sequences are of limited value anyway. Let's think about ways to get
> there:
I really don't think there is any way to get there without creating
gaping security holes in all kinds of client code :-(. If we change
the escaping rules, then a client that is expecting some other rule
than happens to be in force will be subject to trivial SQL-injection
attacks. This will make the autocommit fiasco pale by comparison ...
> For COPY, we would probably have to use a flag in the COPY command
> itself either way (like already done for NULL AS).
The spec-compatibility argument for removing escapes does not apply to
COPY at all, so I see no need to fool with the COPY definition in any
case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-29 19:13:58 | Re: Simplifying unknown-literal handling |
| Previous Message | Andrew - Supernews | 2005-05-29 18:27:59 | Re: Simplifying unknown-literal handling |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2005-05-30 00:16:15 | Re: skip FK trigger on UPDATE |
| Previous Message | Peter Eisentraut | 2005-05-29 18:00:19 | Re: Escape handling in COPY, strings, psql |