Robert Haas writes:
> On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama wrote:
>> Tom Lane wrote:
>>> So I'm not sure whether to fix it, or leave it as a known failure case
>>> in old branches. Comments?
>> As an end user there is one area of the DB that I want to work correctly
>> 100% of the time
On Fri, Jan 21, 2011 at 12:44 PM, Bosco Rama wrote:
> Tom Lane wrote:
>>
>> So I'm not sure whether to fix it, or leave it as a known failure case
>> in old branches. Comments?
>
> I understand the reluctance to fool with stable code. I have zero insight
> into your installed versions distributi
Tom Lane wrote:
>
> So I'm not sure whether to fix it, or leave it as a known failure case
> in old branches. Comments?
I understand the reluctance to fool with stable code. I have zero insight
into your installed versions distribution and backward compatibility needs
so any comment I may have
On Thu, Jan 20, 2011 at 6:14 PM, Tom Lane wrote:
> So I'm not sure whether to fix it, or leave it as a known failure case
> in old branches. Comments?
Since there is a workaround, I think it is best to document it and
leave it as-is.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Bosco Rama writes:
>>> If 'standard_conforming_strings = on' is set in our DB (which is required
>>> for
>>> our app) then the piped restore method (e.g. pg_restore -O backup.dat |
>>> psql)
>>> results in the large objects being corrupted.
> All servers and client tools involved are PG 8.4.6 o
