From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dmitry Belyavsky <beldmit(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
Subject: | Re: Ltree syntax improvement |
Date: | 2020-03-24 23:08:15 |
Message-ID: | 14141.1585091295@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> writes:
> Attached new version of the patch.
I spent a little bit of time looking through this, and have a few
comments:
* You have a lot of places where tests for particular ASCII characters
are done like this:
if ((charlen == 1) && t_iseq(src, '\\'))
This is a tedious and expensive way to spell
if (*src == '\\')
because charlen is necessarily 1 if you are looking at an ASCII character;
there is no allowed backend encoding in which an ASCII character can be
the first byte of a multibyte character. Aside from the direct
simplifications of the tests that this makes possible, I see some places
where you'd not have to pass charlen around, either.
* I spent a fair amount of time thinking that a lot of the added code
was wrong because it was only considering escaping and not
double-quoting. I eventually concluded that the idea is to convert
double-quoting to a pure escape-based representation during input
and store it that way. However, I don't really see why that is either
necessary or a good idea --- the internal storage already has a length
counter for each label. So I think what you really ought to be doing
here is simplifying out both quotes and escapes during ltree_in
and just storing the notionally-represented string internally.
(If I've misunderstood what the plan is, well the utter lack of
documentation in the patch isn't helping.)
* The added test cases seem a bit excessive and repetitive.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-03-24 23:08:31 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Previous Message | Li, Zheng | 2020-03-24 22:32:00 | Re: NOT IN subquery optimization |