| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Michael Meskes <meskes(at)postgresql(dot)org>, "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>, "Takahashi, Ryohei" <r(dot)takahashi_2(at)fujitsu(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "Kuroda, Hayato" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Subject: | Re: SQL statement PREPARE does not work in ECPG |
| Date: | 2019-05-22 13:32:20 |
| Message-ID: | 26097.1558531940@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> This patch seems to have little incidence on the stability, but FWIW I
> am not cool with the concept of asking for objections and commit a
> patch only 4 hours after-the-fact, particularly after feature freeze.
FWIW, I figured it was okay since ECPG has essentially no impact on
the rest of the system. The motivation for having feature freeze is
to get us to concentrate on stability, but any new bugs in ECPG
aren't going to affect the stability of anything else.
Also, I don't think it's that hard to look at this as a bug fix
rather than a new feature. The general expectation is that ECPG
can parse any command the backend can --- that's why we went to
all the trouble of automatically building its grammar from the
backend's. So I was surprised to hear that it didn't work on
some EXECUTE variants, and filling in that gap doesn't seem like a
"new feature" to me. Note the lack of any documentation additions
in the patch.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-05-22 13:46:19 | Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD |
| Previous Message | Amit Kapila | 2019-05-22 12:44:23 | Re: POC: Cleaning up orphaned files using undo logs |