Thread: RE: [HACKERS] pg_dump not in very good shape

>> And a pg_dump that cores trying to dump someone's database is *not*
>> a "minor" problem.
No, I didn't mean minor when it happens, I meant minor to fix.  Sorry.  Of
course it's serious for the user.

>> So I'm leaning towards leaving the pg_dump code as-is and fixing the
>> limitation in pqexpbuffer.
Yes, this is the correct solution.  What's the best way? To check the
incoming string lengths for anything aproaching or greater than 1kB and
slice it up from there?

MikeA

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
>> So I'm leaning towards leaving the pg_dump code as-is and fixing the
>> limitation in pqexpbuffer.

> Yes, this is the correct solution.  What's the best way? To check the
> incoming string lengths for anything aproaching or greater than 1kB and
> slice it up from there?

I don't think we can do that short of writing a complete snprintf
emulation --- so we might as well just use snprintf.
        regards, tom lane

Tom Lane wrote:
> 
> "Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> >> So I'm leaning towards leaving the pg_dump code as-is and fixing the
> >> limitation in pqexpbuffer.
> 
> > Yes, this is the correct solution.  What's the best way? To check the
> > incoming string lengths for anything aproaching or greater than 1kB and
> > slice it up from there?
> 
> I don't think we can do that short of writing a complete snprintf
> emulation --- so we might as well just use snprintf.
> 
>                         regards, tom lane

Can I go ahead and use today's snapshot to write up the diffs for
pg_dump for dumping COMMENT ON statements?

Mike Mascari

Mike Mascari <mascarm@mascari.com> writes:
> Can I go ahead and use today's snapshot to write up the diffs for
> pg_dump for dumping COMMENT ON statements?

Sure --- just don't test it with any long comments ;-)
        regards, tom lane