Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1meHp5-0004Ca-Gu for pgsql-www@arkaria.postgresql.org; Sat, 23 Oct 2021 14:16:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1meHp4-0007m0-AB for pgsql-www@arkaria.postgresql.org; Sat, 23 Oct 2021 14:16:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1meHp4-0007lr-2Y for pgsql-www@lists.postgresql.org; Sat, 23 Oct 2021 14:16:34 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1meHow-0004Cy-U9 for pgsql-www@lists.postgresql.org; Sat, 23 Oct 2021 14:16:33 +0000 Received: by mail-lf1-x12a.google.com with SMTP id br29so181334lfb.7 for ; Sat, 23 Oct 2021 07:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dny5HCSD/UrHdjyH5lrHjvQdWBtxi/w2UK7dtusWGhY=; b=Dr/N8ReKhGDct6pntid2LY3j3wytxns8WoohM4KRWFUyX05S1vBjI/LbiJPpY2/y7i SVOUOLpU9TiDTOZP3M3pHqEFFfknxnSArnwja+Kc9AzpUtq1IaumL1lh9UGRkfIA2fMI YOhPSbVyCxbjpcDUVNFWTIxQC+yP2q1qYpHfkeUFSeA8PaFSyNCbKPKhz44LD1MvW9MK m/KznWom78DjyOMF4UjkgPSw7lT+gYmZB71gsmqvtTqdVUbJzWdTebqssbk5mugZRrR6 GVHuOzcc8jSvPNnpohxxXAWCTMCchc4kzLiF+NmbNVDjzvEb/mJ/v52sE8D67/eU2ehe vCbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dny5HCSD/UrHdjyH5lrHjvQdWBtxi/w2UK7dtusWGhY=; b=UU+ag4gjmizOtgJaF6AYVoUHkxafHfnGt/22vbYcgW3MhXzhUQyQciPuykN2BIBi8M Njki9bvrf38fdWwpfvI3aQmn7rp/PryWE3sNjuqYyNsjdgcLMAmXDolGlfRndbt/nCaL aTS5+/gx/esBJn6qk6Q6pRI4sWdzQesi5a8L6J/Z7s55RQj9MOnOMFBthTc39a6qLf4Q LI/pQD1gWOwX7SR7rZorsBqHUEbIONRuSC9ds15Pcgknci5skhjMiR6AS0YAdj10u0lI wf/90FE49+VTHPTunb6iicbYwW60umzI7S6TpRDDKll4DoCowLk9k0suLQRMVka3+Jch 3x3g== X-Gm-Message-State: AOAM532rSLUqELgFoixC6eIIW8d8Tur6YivpEprVTbi+dx0vsCZD1/q8 RSM25Ip7GvkHvlPFDibIcgaVAGiVb1+eQolUaElMU7bO6di8sQ== X-Google-Smtp-Source: ABdhPJxFywLmTWstPGUX3Ho0gZfPGYIA+T/1sISopye62m2pMe4Ris8V+zxKVnGa85VxOc8l0kHdb/Utz6KxiHy87OY= X-Received: by 2002:a05:6512:21b1:: with SMTP id c17mr4014429lft.266.1634998584746; Sat, 23 Oct 2021 07:16:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Magnus Hagander Date: Sat, 23 Oct 2021 16:16:13 +0200 Message-ID: Subject: Re: [PATCH] pgarchives: Fix database install procedure: remove redundant tables in schema.sql To: =?UTF-8?Q?C=C3=A9lestin_Matte?= Cc: PostgreSQL WWW Content-Type: multipart/alternative; boundary="000000000000da371805cf05c50c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000da371805cf05c50c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 18, 2021 at 6:19 PM C=C3=A9lestin Matte wrote: > Hello, > > While installing pgarchives, I've encountered issues that are addressed i= n > this patch. > Django's model and schema.sql both contain tables that are necessary for > the execution of the application, but are mutually exclusive. > This is due to some fields in the "messages" table that cannot be defined > in > django, and definition of tables in schema.sql that are already created > by django. > Ugh, yeah that is clearly a mess. I thought we had cleaned that up at some point, but clearly we haven't, and tracking changse has been inconsistent. I think the correct solution to the problem is to actually get rid of loader/sql/schema.sql and move it all into the django migrations. Trying to keep track of half in one place and half in another is just going to lead to more problems down the road. So your removal of messages there is a good start, but adding some columns back after the fact in a different file is a big ugh. We should just make all that happen in 0001_initial.py. Additionally, I have two questions: > - Where is the "tsparser" parser defined? (See commit e05f813b of > pgarchives). > It is used in schema.sql, but I haven't found its definition in the > pgarchives, pglister or pgweb repositories. Is it an alias to > pg_catalog.pg_ts_parser? > It's this one over here: https://github.com/postgrespro/pg_tsparser > (I have been able to complete the install procedure by reverting e05f813b= , > but I have no idea what the consequences are for the application) > - Same question for /usr/share/postgresql/12/tsearch_data/pg_dict.stop > I've found pg_dict.syn in pgweb, but not this file. > This is just a textfile with stop words. interestingly enough the prod version for the archives just has the word "sql" in it -- I think there was a great big plan to do somethign good with that, that turned out to never happen. --=20 Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000da371805cf05c50c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 18, 2021 at 6:19 PM C=C3= =A9lestin Matte <celestin.ma= tte@cmatte.me> wrote:
Hello,

While installing pgarchives, I've encountered issues that are addressed= in this patch.
Django's model and schema.sql both contain tables that are necessary fo= r
the execution of the application, but are mutually exclusive.
This is due to some fields in the "messages" table that cannot be= defined in
django, and definition of tables in schema.sql that are already created
by django.

Ugh, yeah that is clearly a = mess. I thought we had cleaned that up at some point, but clearly we haven&= #39;t, and tracking changse has been inconsistent.

I think the correct solution to the problem is to actually get rid of load= er/sql/schema.sql and move it all into the django migrations. Trying to kee= p track of half in one place and half in another is just going to lead to m= ore problems down the road.

So your removal of mes= sages there is a good start, but adding some columns back after the fact in= a different file is a big ugh. We should just make all that happen in 0001= _initial.py.


Additionally, I have two questions:
- Where is the "tsparser" parser defined? (See commit e05f813b of= pgarchives).
It is used in schema.sql, but I haven't found its definition in the
pgarchives, pglister or pgweb repositories. Is it an alias to
pg_catalog.pg_ts_parser?

It's this = one over here:=C2=A0= https://github.com/postgrespro/pg_tsparser

=C2= =A0
(I have been able to complete the install procedure by reverting e05f813b,<= br> but I have no idea what the consequences are for the application)
- Same question for /usr/share/postgresql/12/tsearch_data/pg_dict.stop
I've found pg_dict.syn in pgweb, but not this file.

This is just a textfile with stop words. interestingly eno= ugh the prod version for the archives just has the word "sql" in = it -- I think there was a great big plan to do somethign good with that, th= at turned out to never happen.
=C2=A0

-= -
=C2= =A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
=C2=A0Work: https://www.redpill-linpro.com/<= /a>
--000000000000da371805cf05c50c--