Re: pgbench - refactor init functions with buffers
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - refactor init functions with buffers |
Дата | |
Msg-id | alpine.DEB.2.21.2003281029430.16227@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench - refactor init functions with buffers (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hello Tom, >> I cannot say that I "want" to fix something which already works the same >> way, because it is against my coding principles. [...] >> I counted nearly 3500 calls under src/bin. > > Yeah, that's the problem. If someone does come forward with a patch to do > that, I think it'd be summarily rejected, at least in high-traffic code > like pg_dump. The pain it'd cause for back-patching would outweigh the > value. What about "typedef StringInfoData PQExpBufferData" and replacing PQExpBuffer by StringInfo internally, just keeping the old interface around because it is there? That would remove a few hundreds clocs. ISTM that with inline and varargs macro the substition can be managed reasonably lightly, depending on what level of compatibility is required for libpq: should it be linkability, or requiring a recompilation is ok? A clear benefit is that there are quite a few utils for PQExpBuffer in "fe_utils/string_utils.c" which would become available for StringInfo, which would help using StringInfo without duplicating them. > That being the case, I'd think a better design principle is "make your > new code look like the code around it", Yep. > 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. Well, that is what I was saying, but at 2 against 1, I fold. -- Fabien.
В списке pgsql-hackers по дате отправления: