Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jan 26, 2018 at 11:07 AM, Stephen Frost <sfr...@snowman.net> wrote:
>> I've already had two people mention that it'd be neat to have PG support
>> it, so I don't believe it'd go unused. As for if we should force people
>> to use quotes, my vote would be no because we don't require that for
>> other usage of true/false in the parser and I don't see any reason why
>> this should be different.
> OK. Let's wait a bit and see if anyone else wants to weigh in.
I dunno, this patch seems quite bizarre to me. IIUC, it results in
TRUE/FALSE behaving differently in a partbound_datum than they do
anywhere else in the grammar, to wit that they're effectively just
another spelling for the undecorated literals 't' and 'f', without
anything indicating that they're boolean. That seems wrong from a
data typing standpoint. And even if it's really true that we'd
rather lose type information for partbound literals, a naive observer
would probably think that these should decay to the strings "true"
and "false" not "t" and "f" (cf. opt_boolean_or_string).
I've not paid any attention to this thread up to now, so maybe there's
a rational explanation for this choice that I missed. But mucking
with makeBoolAConst like that doesn't seem to me to pass the smell
test. I'm on board with the stated goal of allowing TRUE/FALSE here,
but having to contort the grammar output like this suggests that
there's something wrong in parse analysis of partbound_datum.
regards, tom lane
PS: the proposed documentation wording is too verbose by half.
I'd just cut it down to "<literal constant>".
