čt 26. 8. 2021 v 17:25 odesílatel Jacob Champion
napsal:
> On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote:
> > On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion
> wrote:
> > >
> > > Does there need to be any sanity check for overlapping ranges between
> > > the combining and fullwidth sets? T
On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote:
> On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
> >
> > Does there need to be any sanity check for overlapping ranges between
> > the combining and fullwidth sets? The Unicode data on a dev's machine
> > would have to be broken somehow
I wrote:
> On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion
wrote:
> It seems the logical thing to do is revert my 0001 and 0002 and go back
to something much closer to Jacob's patch, plus a big comment explaining
that the order in which the searches happen matters.
I pushed Jacob's patch with the
On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
>
> Does there need to be any sanity check for overlapping ranges between
> the combining and fullwidth sets? The Unicode data on a dev's machine
> would have to be broken somehow for that to happen, but it could
> potentially go undetected for
On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
>
> On Fri, 2021-08-20 at 13:05 -0400, John Naylor wrote:
> > On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion
wrote:
> > > I guess it just depends on what the end result looks/performs like.
> > > We'd save seven hops or so in the worst case?
>
On Fri, 2021-08-20 at 13:05 -0400, John Naylor wrote:
> On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion wrote:
> > I guess it just depends on what the end result looks/performs like.
> > We'd save seven hops or so in the worst case?
>
> Something like that. Attached is what I had in mind (using re
I plan to commit my proposed v2 this week unless I hear reservations about
my adjustments, or bikeshedding. I'm thinking of squashing 0001 and 0002.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion wrote:
>
> On Thu, 2021-08-19 at 13:49 -0400, John Naylor wrote:
> > I had a couple further thoughts:
> >
> > 1. The coding historically used normal comparison and branching for
> > everything, but recently it only does that to detect control
> > char
On Thu, 2021-08-19 at 13:49 -0400, John Naylor wrote:
> I had a couple further thoughts:
>
> 1. The coding historically used normal comparison and branching for
> everything, but recently it only does that to detect control
> characters, and then goes through a binary search (and with this
> patch
On 16.08.21 22:06, John Naylor wrote:
Peter, does the combining char table exclude values > 0x for size
reasons, correctness, or some other consideration?
I don't remember a reason, other than perhaps making the generated table
match the previous manual table in scope. IIRC, the previou
I wrote:
> On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier
wrote:
> >
> > On Thu, Aug 12, 2021 at 05:13:31PM -0400, John Naylor wrote:
> > > I'm a bit concerned about the build dependencies not working right,
but
> > > it's not clear it's even due to the patch. I'll spend some time
> > > investi
On Mon, Aug 16, 2021 at 1:04 PM Jacob Champion wrote:
>
> On Mon, 2021-08-16 at 11:24 -0400, John Naylor wrote:
> >
> > On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier
wrote:
> >
> > > How large do libpgcommon deliverables get with this patch? Skimming
> > > through the patch, that just looks l
On Mon, 2021-08-16 at 11:24 -0400, John Naylor wrote:
>
> On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier wrote:
>
> > How large do libpgcommon deliverables get with this patch? Skimming
> > through the patch, that just looks like a couple of bytes, still.
>
> More like a couple thousand byte
On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier
wrote:
>
> On Thu, Aug 12, 2021 at 05:13:31PM -0400, John Naylor wrote:
> > I'm a bit concerned about the build dependencies not working right, but
> > it's not clear it's even due to the patch. I'll spend some time
> > investigating next week.
>
>
On Thu, Aug 12, 2021 at 05:13:31PM -0400, John Naylor wrote:
> I'm a bit concerned about the build dependencies not working right, but
> it's not clear it's even due to the patch. I'll spend some time
> investigating next week.
How large do libpgcommon deliverables get with this patch? Skimming
t
On Thu, 2021-08-12 at 17:13 -0400, John Naylor wrote:
> The patch looks pretty good to me. I just have a stylistic suggestion
> which I've attached as a text file.
Getting rid of the "clever addition" looks much better to me, thanks. I
haven't verified the changes to the doc comment, but your desc
The patch looks pretty good to me. I just have a stylistic suggestion which
I've attached as a text file. There are also some outdated comments that
are not the responsibility of this patch, but I kind of want to fix them
now:
* - Hangul Jamo medial vowels and final consonants (U+1160-U+11FF)
*
On Thu, Aug 12, 2021 at 12:46 PM Pavel Stehule
wrote:
> did you run make clean?
>
> when I executed just patch & make, it didn't work
I did not, but I always have --enable-depend on. I tried again with make
clean, and ccache -C just in case, and it works now.
On Thu, Aug 12, 2021 at 12:54 PM Ja
On Thu, 2021-08-12 at 12:36 -0400, John Naylor wrote:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in
> case that matters) and the example shown at the top of the thread shows no
> difference:
>
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=# SEL
čt 12. 8. 2021 v 18:36 odesílatel John Naylor
napsal:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac,
> in case that matters) and the example shown at the top of the thread shows
> no difference:
>
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=# SELE
I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in
case that matters) and the example shown at the top of the thread shows no
difference:
john.naylor=# \pset border 2
Border style is 2.
john.naylor=# SELECT U&'\+01F603';
+--+
| ?column? |
+--+
| 😃|
čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion
napsal:
> On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> > I note that the doc comment for ucs_wcwidth()...
> >
> > > *- Spacing characters in the East Asian Wide (W) or East Asian
> > > * FullWidth (F) category as defined
On Fri, 2021-07-23 at 17:42 +0200, Pavel Stehule wrote:
> čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion napsal:
> >
> > Pavel, I'd be interested to see what your benchmarks find with this
> > code. Does this fix the original issue for you?
>
> I can confirm that the original issue is fixed.
Hi
čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion
napsal:
> On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> > I note that the doc comment for ucs_wcwidth()...
> >
> > > *- Spacing characters in the East Asian Wide (W) or East Asian
> > > * FullWidth (F) category as def
On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> I note that the doc comment for ucs_wcwidth()...
>
> > *- Spacing characters in the East Asian Wide (W) or East Asian
> > * FullWidth (F) category as defined in Unicode Technical
> > * Report #11 have a column widt
On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> On Mon, 2021-07-19 at 13:13 +0200, Laurenz Albe wrote:
> > That could be adapted; the question is if the approach as such is
> > desirable or not. This is necessarily a moving target, at the rate
> > that emojis are created and added to Un
On Mon, 2021-07-19 at 13:13 +0200, Laurenz Albe wrote:
> On Mon, 2021-07-19 at 16:46 +0900, Michael Paquier wrote:
> > > In your opinion, would the current one-line patch proposal make things
> > > strictly better than they are today, or would it have mixed results?
> > > I'm wondering how to help
On Mon, 2021-07-19 at 16:46 +0900, Michael Paquier wrote:
> > In your opinion, would the current one-line patch proposal make things
> > strictly better than they are today, or would it have mixed results?
> > I'm wondering how to help this patch move forward for the current
> > commitfest, or if w
po 19. 7. 2021 v 9:46 odesílatel Michael Paquier
napsal:
> On Wed, Jul 07, 2021 at 06:03:34PM +, Jacob Champion wrote:
> > I would guess that's the key issue here. If we choose a particular
> > width for emoji characters, is there anything keeping a terminal's font
> > from doing something di
On Wed, Jul 07, 2021 at 06:03:34PM +, Jacob Champion wrote:
> I would guess that's the key issue here. If we choose a particular
> width for emoji characters, is there anything keeping a terminal's font
> from doing something different anyway?
I'd say that we are doing our best in guessing wha
st 7. 7. 2021 v 20:03 odesílatel Jacob Champion
napsal:
> On Mon, 2021-04-05 at 14:07 +0900, Kyotaro Horiguchi wrote:
> > At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule <
> pavel.steh...@gmail.com> wrote in
> > > with this patch, the formatting is correct
> >
> > I think the hardest point of th
On Mon, 2021-04-05 at 14:07 +0900, Kyotaro Horiguchi wrote:
> At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule
> wrote in
> > with this patch, the formatting is correct
>
> I think the hardest point of this issue is that we don't have a
> reasonable authoritative source that determines characte
po 5. 4. 2021 v 7:07 odesílatel Kyotaro Horiguchi
napsal:
> At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule
> wrote in
> > with this patch, the formatting is correct
>
> I think the hardest point of this issue is that we don't have a
> reasonable authoritative source that determines character w
At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule
wrote in
> with this patch, the formatting is correct
I think the hardest point of this issue is that we don't have a
reasonable authoritative source that determines character width. And
that the presentation is heavily dependent on environment.
pá 2. 4. 2021 v 11:37 odesílatel Laurenz Albe
napsal:
> On Fri, 2021-04-02 at 10:45 +0200, Pavel Stehule wrote:
> > I am checked an query from
> https://www.depesz.com/2021/04/01/waiting-for-postgresql-14-add-unistr-function/
> article.
> >
> > postgres=# SELECT U&'\+01F603';
> > ┌──┐
> >
On Fri, 2021-04-02 at 10:45 +0200, Pavel Stehule wrote:
> I am checked an query from
> https://www.depesz.com/2021/04/01/waiting-for-postgresql-14-add-unistr-function/
> article.
>
> postgres=# SELECT U&'\+01F603';
> ┌──┐
> │ ?column? │
> ╞══╡
> │ 😃│
> └──┘
> (1 r
Hi
I am checked an query from
https://www.depesz.com/2021/04/01/waiting-for-postgresql-14-add-unistr-function/
article.
postgres=# SELECT U&'\+01F603';
┌──┐
│ ?column? │
╞══╡
│ 😃│
└──┘
(1 row)
The result is not correct. Emoji has width 2 chars, but psql calculate
37 matches
Mail list logo
