Hi,
>
> > The fundamental question though is should we allow primary, unique
> > CONSTRAINTS which use the index mechanism just as an implementation to
> be
> > created using the "INCLUDING INDEXES" mechanism.
>
> Yeah, this bizarreness was foreseen and agreed to back when we set up
> LIKE INCLUDI
The following bug has been logged online:
Bug reference: 3795
Logged by: Lou Duchez
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta 3
Operating system: Windows 2003
Description:pg_dump is mis-dumping columns containing line breaks
Details:
Hello,
My c
"Lou Duchez" <[EMAIL PROTECTED]> writes:
> My copy of PostgreSQL has standard_conforming_strings set to "on", and when
> I attempt to pg_dump tables that have strings containing CR/LFs, the data
> dumps in a format that psql cannot then reload.
It works fine here. Please provide a *complete* exam
> "Lou Duchez" <[EMAIL PROTECTED]> writes:
> > My copy of PostgreSQL has standard_conforming_strings set to "on", and when
> > I attempt to pg_dump tables that have strings containing CR/LFs, the data
> > dumps in a format that psql cannot then reload.
>
> It works fine here. Please provide a *co
[EMAIL PROTECTED] writes:
> The two versions of PostgreSQL produce slightly different results.
Yeah, that's an intentional change.
> The 8.3 version, with the unescaped line breaks, confuses the heck out
> of psql.
Works fine for me --- I can load either dump file into either version of
psql.
M
I wrote:
> Maybe your test case involves letting Windows mangle the line endings?
On reflection, I'm sure that's exactly what's happening. I now remember
that one of the reasons for the old dump behavior was to make COPY data
a bit safer against line-ending mangling. I've reverted this rather
il
