Re: [HACKERS] Max Query length string
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Max Query length string |
Дата | |
Msg-id | 337.933259499@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Max Query length string ("Ansley, Michael" <Michael.Ansley@intec.co.za>) |
Список | pgsql-hackers |
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes: > What I'd like to do is use the expandable buffer that I wrote for psql, and > any other client-side utils that require it; and then use stringinfo for > anything new that requires an expanable buffer in the backend (this will > happen anyway, stringinfo's here to stay). This removes any dependency > between the client-side and server-side components of the system. There is precedent for sharing low-level code between frontend and backend, with maybe a #define or two to handle differences like palloc <=> malloc. See dllist.c and some of the MULTIBYTE routines that get included into frontend libpq. The main restriction is that you can't really report any errors from such code, since error handling in the backend is via elog() which won't exist in clients. However, reporting errors from a client-side library is going to be ticklish anyway --- if you try to do anything more than return an error-code return value, some clients will be unhappy with you. So it's not as big a restriction as it might appear. In short, I'd suggest seeing whether you can't make stringinfo portable to a frontend environment; and then merge any good ideas you had in your code into it (or vice versa if that seems easier). Keeping two different modules that accomplish more or less the same thing doesn't strike me as a win. regards, tom lane
В списке pgsql-hackers по дате отправления: