Обсуждение: [PATCH] pgweb: Add SEARCH_DSN to example settings.py
Hello, Defining SEARCH_DSN is necessary to install the search functionality in pgweb, although this is not explained anywhere. This patch adds SEARCH_DSN in the example settings.py so that users know that this variable must be defined. Cheers, -- Célestin Matte
Вложения
On 10/22/21 11:08 AM, Célestin Matte wrote: > Hello, > > Defining SEARCH_DSN is necessary to install the search functionality in pgweb, although this is not explained anywhere. > This patch adds SEARCH_DSN in the example settings.py so that users know that this variable must be defined. ...this perhaps explains why I've never gotten the search utility to work in my local environment. In general I'm OK with this, but perhaps we leave the string empty with instructions to fill the connection string to the DB that is hosting the search schema. Jonathan
Вложения
On Fri, Oct 22, 2021 at 6:10 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 10/22/21 11:08 AM, Célestin Matte wrote:
> Hello,
>
> Defining SEARCH_DSN is necessary to install the search functionality in pgweb, although this is not explained anywhere.
> This patch adds SEARCH_DSN in the example settings.py so that users know that this variable must be defined.
...this perhaps explains why I've never gotten the search utility to
work in my local environment.
In general I'm OK with this, but perhaps we leave the string empty with
instructions to fill the connection string to the DB that is hosting the
search schema.
I think having a default like in this patch is better. Otherwise it could randomly connect to a database with the same name as the user for example, which might actually happen in dev scenarios. So if we want it empty we'd also need to add code to check if it's set or not before trying to use it - seems easier to set the default and have it fail :)
Hi, I'm reviewing the patches I sent a few months ago and this short one seems to have been left mid-discussion. > I think having a default like in this patch is better. Otherwise it could randomly connect to a database with the samename as the user for example, which might actually happen in dev scenarios. So if we want it empty we'd also need toadd code to check if it's set or not before trying to use it - seems easier to set the default and have it fail :) I guess it's OK as-is, then? -- Célestin Matte
On Wed, Jan 19, 2022 at 3:30 PM Célestin Matte <celestin.matte@cmatte.me> wrote: > > Hi, > > I'm reviewing the patches I sent a few months ago and this short one seems to have been left mid-discussion. > > > I think having a default like in this patch is better. Otherwise it could randomly connect to a database with the samename as the user for example, which might actually happen in dev scenarios. So if we want it empty we'd also need toadd code to check if it's set or not before trying to use it - seems easier to set the default and have it fail :) > > I guess it's OK as-is, then? Yeah, indeed that was forgotten. Patch now conflicted with your own patch for archives frontend address. I adjusted it for that and applied. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/