| 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: | Ian Boardman <isb0459(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14693: create materialized view forces btrim |
| Date: | 2017-06-06 23:47:12 |
| Message-ID: | 6579.1496792832@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> I don't know why btrim is the canonical spelling of the trim function but,
> like Tom said, it is. The choice of btrim or trim will not influence the
> end result of the query in any way (though I don't think btrim accepts the
> "from" keyword that trim does).
FWIW, btrim is just a plain function. Our grammar maps the weird syntax
defined by the SQL standard for TRIM() into a call of btrim, ltrim, or
rtrim depending on what keywords appear. The functionality is the same
whether you go through that syntax or just use btrim directly.
I'm inclined to suspect that the OP's real problem has to do with
confusion between empty strings and nulls, but it's hard to be sure
with no concrete example.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2017-06-07 00:52:50 | Re: BUG #14682: row level security not work with partitioned table |
| Previous Message | David G. Johnston | 2017-06-06 23:29:32 | Re: BUG #14693: create materialized view forces btrim |