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
|
Список | 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 по дате отправления: