Re: inconsistency and inefficiency in setup_conversion()

John Naylor writes: > Since it's been a few months since last discussion, I'd like to > summarize the purpose of this patch and advocate for its inclusion in > v12: Pushed after some review and correction. Notably, I didn't like leaving the info about the encoding lookup out of bki.sgml, so I

Re: inconsistency and inefficiency in setup_conversion()

On 12/1/18, Dmitry Dolgov <9erthali...@gmail.com> wrote: > I see that the author keeps patch updated, but I'm a bit worried because of > lack of full review since probably May. I'm moving it to the next CF, let's > see > if there would be more feedback. > > P.S. adding Daniel, since he is assigned

Re: inconsistency and inefficiency in setup_conversion()

> On Mon, Nov 26, 2018 at 9:31 AM John Naylor wrote: > > v7 is a rebase over recent catalog changes. Thanks for working on this, I see that the author keeps patch updated, but I'm a bit worried because of lack of full review since probably May. I'm moving it to the next CF, let's see if there

Re: inconsistency and inefficiency in setup_conversion()

v7 is a rebase over recent catalog changes. -John Naylor From 52aff43dcc91733c1b941fed4582d9c0602004d0 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Sat, 13 Oct 2018 19:28:08 +0700 Subject: [PATCH v7 1/2] Add pg_language lookup. This didn't seem worth doing before, but an upcoming commit

Re: inconsistency and inefficiency in setup_conversion()

Attached is v6, a simple rebase. -John Naylor From e37cb80ab8e7baaa5231fc3b8dbc9d96ec253018 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Sat, 13 Oct 2018 19:28:08 +0700 Subject: [PATCH v6 1/2] Add pg_language lookup. This didn't seem worth doing before, but an upcoming commit will add 88

Re: inconsistency and inefficiency in setup_conversion()

On 10/2/18, Michael Paquier wrote: > v4 does not apply anymore. I am moving this patch to next commit fest, > waiting on author. v5 attached. -John Naylor From ea0a180bde325b0383ce7f0b3d48d1ce9e941393 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Mon, 2 Jul 2018 12:52:07 +0700 Subject:

Re: inconsistency and inefficiency in setup_conversion()

Hi John, On Mon, Jul 02, 2018 at 01:59:03PM +0700, John Naylor wrote: > I've attached v4, which is a rebase plus some comment revisions. v4 does not apply anymore. I am moving this patch to next commit fest, waiting on author. -- Michael signature.asc Description: PGP signature

Re: inconsistency and inefficiency in setup_conversion()

I've attached v4, which is a rebase plus some comment revisions. -John Naylor From 4d1cb1d40c5c79c732e5433e95f8560fb41e20bd Mon Sep 17 00:00:00 2001 From: John Naylor Date: Mon, 2 Jul 2018 12:52:07 +0700 Subject: [PATCH v4 1/2] Add pg_language lookup. This didn't seem worth doing before, but an

Re: inconsistency and inefficiency in setup_conversion()

On Fri, May 18, 2018 at 10:53 PM, John Naylor wrote: > On 5/17/18, Thomas Munro wrote: >> Hi John, >> >> This failed for my patch testing robot on Windows, with this message[1]: > ... >> I see that you changed src/backend/catalog/Makefile to

Re: inconsistency and inefficiency in setup_conversion()

On 5/17/18, Thomas Munro wrote: > Hi John, > > This failed for my patch testing robot on Windows, with this message[1]: ... > I see that you changed src/backend/catalog/Makefile to pass the new -I > switch to genbki.pl. I think for Windows you might need to add it

Re: inconsistency and inefficiency in setup_conversion()

On Thu, May 3, 2018 at 12:19 AM, John Naylor wrote: > Attached is a draft patch to do this, along with the conversion script > used to create the entries. In writing this, a few points came up that > are worth bringing up: Hi John, This failed for my patch testing robot on

Re: inconsistency and inefficiency in setup_conversion()

On 4/28/18, Tom Lane wrote: > John Naylor writes: >> Solution #1 - As alluded to in [1], turn the conversions into >> pg_proc.dat and pg_conversion.dat entries. Teach genbki.pl to parse >> pg_wchar.h to map conversion names to numbers. >> Pros: >> -likely

Re: inconsistency and inefficiency in setup_conversion()

John Naylor writes: > Taking a close look at the result of setup_conversion(), wrong or at > least confusing comments are applied to the functions. Ugh. Between that and the large chunk of initdb runtime eaten by setup_conversion(), that seems like plenty of reason to redo

inconsistency and inefficiency in setup_conversion()

Taking a close look at the result of setup_conversion(), wrong or at least confusing comments are applied to the functions. Consider this family of conversions: select conproc, conname from pg_conversion where conproc = 'utf8_to_win'::regproc order by oid; conproc | conname