From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clean up command argument assembly |
Date: | 2024-02-04 18:02:03 |
Message-ID: | 3808290.1707069723@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> Should anything outside of libpq be using PQExpBuffer?
Perhaps not. PQExpBuffer's behavior for OOM cases is designed
specifically for libpq, where exit-on-OOM is not okay and we
can hope to include failure checks wherever needed. For most
of our application code, we'd much rather just exit-on-OOM
and not have to think about failure checks at the call sites.
Having said that, converting stuff like pg_dump would be quite awful
in terms of code churn and creating a back-patching nightmare.
Would it make any sense to think about having two sets of
routines with identical call APIs, but different failure
behavior, so that we don't have to touch the callers?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2024-02-04 18:02:46 | Re: Patch: Add parse_type Function |
Previous Message | David E. Wheeler | 2024-02-04 17:51:29 | Patch: Add parse_type Function |