Re: [HACKERS] pg_dump not in very good shape

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pg_dump not in very good shape
Дата
Msg-id 20475.948041064@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: [HACKERS] pg_dump not in very good shape  ("Ansley, Michael" <Michael.Ansley@intec.co.za>)
Ответы Re: [HACKERS] pg_dump not in very good shape  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> Tom, I went through all the places in pg_dump where a format string was used
> to add a string to the buffer (I believe it's only a problem when using
> snprintf, which, I think, is only used if you pass a format string), and
> either removed the format string by passing in a single variable at a time,
> or making sure that only things like db object names (which have a size
> limit significantly less than 1kB) were passed in using a format
> string.

Yes, this is pretty much what the alternative is if we don't want to
rely on vsnprintf().  However, if you submitted changes along that line,
they haven't been applied yet.

> Of course, maybe I missed some places, but it shouldn't be a real
> problem.

Well, that's what the risk is.  Not only might you have missed an
obscure case or two (which Murphy's Law says we won't notice till
after release); but everyone who touches pg_dump from here on out
risks getting burnt by this non-obvious limit.

And a pg_dump that cores trying to dump someone's database is *not*
a "minor" problem.

So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] I think we need an explicit parsetree node for CAST
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] SELECT...FOR UPDATE OF class_name