| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Adding SHOW CREATE TABLE |
| Date: | 2023-05-20 18:19:10 |
| Message-ID: | 877833.1684606750@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sat, May 20, 2023 at 10:26 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> Clearly any client using libpq can conveniently call code which is in
>> libpq.
> Clearly there are clients that don't use libpq. JDBC comes to mind.
Yeah. I'm also rather concerned about the bloat factor; it's
hardly unlikely that this line of development would double the
size of libpq, to add functionality that only a small minority
of applications would use. A client-side implementation also has
no choice but to cope with multiple server versions, and to
figure out what it's going to do about a too-new server.
Up to now we broke compatibility between libpq and server maybe
once every couple decades, but it'd be once a year for this.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2023-05-20 18:33:19 | Re: Adding SHOW CREATE TABLE |
| Previous Message | David G. Johnston | 2023-05-20 17:31:54 | Re: Adding SHOW CREATE TABLE |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2023-05-20 18:33:19 | Re: Adding SHOW CREATE TABLE |
| Previous Message | David G. Johnston | 2023-05-20 17:31:54 | Re: Adding SHOW CREATE TABLE |