| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: initdb's -c option behaves wrong way? |
| Date: | 2024-01-17 20:33:02 |
| Message-ID: | 2063810.1705523582@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> However ... I don't like the patch much. It seems to have left
> the code in a rather random state. Why, for example, didn't you
> keep all the code that constructs the "newline" value together?
After thinking about it a bit more, I don't see why you didn't just
s/strncmp/strncasecmp/ and call it good. The messiness seems to be
a result of your choice to replace the GUC's case as shown in the
file with the case used on the command line, which is not better
IMO. We don't change our mind about the canonical spelling of a
GUC because somebody varied the case in a SET command.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-01-17 20:58:10 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
| Previous Message | Tom Lane | 2024-01-17 20:26:10 | Re: initdb's -c option behaves wrong way? |