Re: pgbench - refactor init functions with buffers
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - refactor init functions with buffers |
Дата | |
Msg-id | alpine.DEB.2.21.2003290727580.16227@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench - refactor init functions with buffers (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
Hello Andres, >> That being the case, I'd think a better design principle is "make your >> new code look like the code around it", which would tend to weigh against >> introducing StringInfo uses into pgbench when there's none there now and >> a bunch of PQExpBuffer instead. So I can't help thinking the advice >> you're being given here is suspect. > > I don't agree with this. This is a "fresh" usage of StringInfo. That's > different to adding one new printed line among others built with > pqexpbuffer. If we continue adding large numbers of new uses of both > pieces of infrastructure, we're just making things more confusing. My 0.02 € : - I'm in favor or having one tool for one purpose, so a fe/be common StringInfo interface is fine with me; - I prefer to avoid using both PQExpBuffer & StringInfo in the same file, because they do the exact same thing and it is locally confusing; - I'd be fine with switching all of pgbench to StringInfo, as there are only 31 uses; - But, pgbench relies on psql scanner, which uses PQExpBuffer in PsqlScanState, so mixing is unavoidable, unless PQExpBuffer & StringInfo are the same thing (i.e. typedef + cpp/inline/function wrappers); - There are 1260 uses of PQExpBuffer in psql that, although they are trivial, I'm in no hurry to update. -- Fabien.
В списке pgsql-hackers по дате отправления: