| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: failing to build preproc.c on solaris with sun studio |
| Date: | 2022-09-02 17:56:44 |
| Message-ID: | 997987.1662141404@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I also wonder if we shouldn't just make ecpg optional at some point. Or even
> move it out of the tree.
The reason it's in the tree is to ensure its grammar stays in sync
with the core grammar, and perhaps more to the point, that it's
possible to build its grammar at all. If it were at arm's length,
we'd probably not have noticed the conflict over STRING in the JSON
patches until unpleasantly far down the road (to mention just the
most recent example). However, those aren't arguments against
making it optional-to-build like the PLs are.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-09-02 18:15:53 | minimum perl version |
| Previous Message | Andres Freund | 2022-09-02 17:40:33 | Re: failing to build preproc.c on solaris with sun studio |