Thread: BUG #1819: COPY filename rejects Windows format path

BUG #1819: COPY filename rejects Windows format path

From
"Steve Peterson"
Date:
The following bug has been logged online:

Bug reference:      1819
Logged by:          Steve Peterson
Email address:      steve@zpfe.com
PostgreSQL version: 8.0.3
Operating system:   Windows XP SP 2
Description:        COPY filename rejects Windows format path
Details:

Running COPY FROM on a Windows server; using a Windows-format fully
qualified path with backslashes results in the backslashes being interpreted
as escapes.

Re: BUG #1819: COPY filename rejects Windows format path

From
Richard Huxton
Date:
Steve Peterson wrote:
>
> Running COPY FROM on a Windows server; using a Windows-format fully
> qualified path with backslashes results in the backslashes being interpreted
> as escapes.

Did you escape the backslashes: C:\\Windows\\Path ?

--
   Richard Huxton
   Archonet Ltd

Re: BUG #1819: COPY filename rejects Windows format path

From
John R Pierce
Date:
Steve Peterson wrote:

> Running COPY FROM on a Windows server; using a Windows-format fully
> qualified path with backslashes results in the backslashes being interpreted
> as escapes.

Windows APIs are perfectly happy with regular / forward slashes in pathnames,
in fact, I use them everywhere BUT in command line interfaces.

Re: BUG #1819: COPY filename rejects Windows format path

From
Steve Peterson
Date:
At 09:47 AM 8/11/2005, Richard Huxton wrote:
>Steve Peterson wrote:
>>Running COPY FROM on a Windows server; using a Windows-format fully
>>qualified path with backslashes results in the backslashes being interpreted
>>as escapes.
>
>Did you escape the backslashes: C:\\Windows\\Path ?

Nope.  I used a standard Windows path, copied from the address field in
Windows explorer.

I see now on
http://www.postgresql.org/docs/8.0/interactive/sql-syntax.html#SQL-SYNTAX-CONSTANTS
(I know, RTFM) that it's documented that the SQL string literal is extended
to accept backslash as an escape, so this is a documented behavior.  Can I
convert this bug into a docs bug -- to mention the escaping process
wherever a filename is specified in a SQL string constant?

S