Re: Supporting = operator in gin/gist_trgm_ops

On Mon, Oct 26, 2020 at 12:19 PM Tom Lane wrote: > > Julien Rouhaud writes: > > On Mon, Oct 26, 2020 at 5:03 AM Tom Lane wrote: > >> I think you may be overoptimistic about being able to use the identical > >> code path without regard for LIKE wildcards; but certainly it should be > >> possible

Re: Supporting = operator in gin/gist_trgm_ops

Julien Rouhaud writes: > On Mon, Oct 26, 2020 at 5:03 AM Tom Lane wrote: >> I think you may be overoptimistic about being able to use the identical >> code path without regard for LIKE wildcards; but certainly it should be >> possible to do this with not a lot of new code. +1. > Well, that's wh

Re: The ultimate extension hook.

> On 10/23/2020 9:31 AM Jehan-Guillaume de Rorthais wrote: > [...] > * useless with encrypted traffic > > So, +1 for such hooks. > > Regards, Ultimately Postgresql is supposed to be extensible. I don't see an API hook as being some crazy idea even if some may not like what I might want to use

Re: Supporting = operator in gin/gist_trgm_ops

On Mon, Oct 26, 2020 at 12:02 PM Julien Rouhaud wrote: > > On Mon, Oct 26, 2020 at 5:03 AM Tom Lane wrote: > > > > Julien Rouhaud writes: > > > A french user recently complained that with an index created using > > > gin_trgm_ops (or gist_trgm_ops), you can use the index with a clause > > > like

Re: Supporting = operator in gin/gist_trgm_ops

On Mon, Oct 26, 2020 at 5:03 AM Tom Lane wrote: > > Julien Rouhaud writes: > > A french user recently complained that with an index created using > > gin_trgm_ops (or gist_trgm_ops), you can use the index with a clause > > like > > col LIKE 'something' > > but not > > col = 'something' > > Huh, I

A couple questions about ordered-set aggregates

I find I am allowed to create an ordered-set aggregate with a non-empty direct argument list and no finisher function. Am I right in thinking that's kind of nonsensical, as nothing will ever look at the direct args? Also, the syntax summary shows PARALLEL = { SAFE | RESTRICTED | UNSAFE } in the or

Re: [patch] Fix checksum verification in base backups for zero page headers

On Fri, Oct 23, 2020 at 08:00:08AM +0900, Michael Paquier wrote: > Yeah, we could try to make the logic a bit more complicated like > that. However, for any code path relying on a page read without any > locking insurance, we cannot really have a lot of trust in any of the > fields assigned to the

Re: MultiXact\SLRU buffers configuration

Hi! On Mon, Sep 28, 2020 at 5:41 PM Andrey M. Borodin wrote: > > 28 авг. 2020 г., в 23:08, Anastasia Lubennikova > > написал(а): > > > > 1) The first patch is sensible and harmless, so I think it is ready for > > committer. I haven't tested the performance impact, though. > > > > 2) I like the

Re: Mop-up around psql's \connect behavior

At Fri, 23 Oct 2020 17:12:44 -0400, Tom Lane wrote in > Kyotaro Horiguchi writes: > > At Thu, 22 Oct 2020 15:23:04 -0400, Tom Lane wrote in > >> ... The only real objection I can see is that it could > >> hold a server connection open when the user thinks there is none; > >> but that could onl

Re: Allow deleting enum value

On Wed, Oct 07, 2020 at 11:47:07PM +0300, Maksim Kita wrote: > I like the idea, during prototype I added additional column and modified > enum_in method. But enum_in is called in contexts that can be important > for user (like comparisons). ... > postgres=# ALTER TYPE test_enum DELETE VALUE '2'; >

Re: POC: contrib/unaccent as IMMUTABLE

On Sun, Oct 4, 2020 at 4:19 AM Tom Lane wrote: > Tomas Vondra writes: > > As for the patch, I wonder if we want to make this change. I'm not very > > familiar with how unaccent works, but if changes to unicode rules would > > really silently break indexes, it's kinda similar to the collation > >

Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour

On Fri, Oct 23, 2020 at 11:09:26PM +0300, Heikki Linnakangas wrote: > Findings in detail follow. Are you working on a patch for these ? Otherwise, since I started something similar in April, I could put something together based on comments you've gotten here. -- Justin

Re: bulk typos

Heikki Linnakangas writes: > On 25/10/2020 21:48, Justin Pryzby wrote: >> Heikki, do you remember what this means ? >> +++ b/src/backend/catalog/storage.c >> + * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear >> + * unbetimes. It'd probably be OK to keep it in TopTransac

Re: Supporting = operator in gin/gist_trgm_ops

Julien Rouhaud writes: > A french user recently complained that with an index created using > gin_trgm_ops (or gist_trgm_ops), you can use the index with a clause > like > col LIKE 'something' > but not > col = 'something' Huh, I'd supposed we did that already. > even though both clauses are tec

Re: bulk typos

On 25/10/2020 21:48, Justin Pryzby wrote: On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote: I needed another distraction so bulk-checked for typos, limited to comments in *.[ch]. I'm not passionate about this, but it serves the purpose of reducing the overhead of fixing them indivi

Re: bulk typos

On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote: > I needed another distraction so bulk-checked for typos, limited to comments in > *.[ch]. > > I'm not passionate about this, but it serves the purpose of reducing the > overhead of fixing them individually. I happened across this old

Re: Commitfest manager 2020-11

On 20.10.2020 10:30, gkokola...@pm.me wrote: ‐‐‐ Original Message ‐‐‐ [snip] Wow, that was well in advance) I am willing to assist if you need any help. Indeed it was a bit early. I left for vacation after that. For the record, I am newly active to the community. In our PUG, in S

Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)

Noah Misch writes: > Each elog(FATAL) check deserves a STATEMENT field if it fires, so I think that > would be too early to clear. Here's an version fixing the defects. In > worker_spi_main(), the timing now mirrors postgres.c. initialize_worker_spi() > is doing something not directly possible

Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)

On Sun, Oct 25, 2020 at 10:52:50AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sat, Oct 17, 2020 at 08:39:35AM -0700, Peter Geoghegan wrote: > >> I also prefer 2. > > > Thanks. Here is the pair of patches I plan to use. The second is > > equivalent > > to v0; I just added a log message.

Re: deferred primary key and logical replication

On Mon, 5 Oct 2020 at 08:34, Amit Kapila wrote: > On Mon, May 11, 2020 at 2:41 AM Euler Taveira > wrote: > > > > Hi, > > > > While looking at an old wal2json issue, I stumbled on a scenario that a > table > > with a deferred primary key is not updatable in logical replication. > AFAICS it > > ha

Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)

Noah Misch writes: > On Sat, Oct 17, 2020 at 08:39:35AM -0700, Peter Geoghegan wrote: >> I also prefer 2. > Thanks. Here is the pair of patches I plan to use. The second is equivalent > to v0; I just added a log message. The change in worker_spi_main seems a little weird/lazy. I'd be inclined

Supporting = operator in gin/gist_trgm_ops

Hello, A french user recently complained that with an index created using gin_trgm_ops (or gist_trgm_ops), you can use the index with a clause like col LIKE 'something' but not col = 'something' even though both clauses are technically identical. That's clearly not a high priority thing to su

Re: Collation versioning

On Sun, Oct 25, 2020 at 10:36 AM Thomas Munro wrote: > > On Fri, Oct 23, 2020 at 2:07 AM Julien Rouhaud wrote: > > While reviewing the changes, I found a couple of minor issues > > (inherited from the previous versions). It's missing a > > free_objects_addresses in recordDependencyOnCollations,

Re: Fix typo in src/backend/utils/cache/lsyscache.c

On Sun, 25 Oct 2020 at 14:23, Hou, Zhijie wrote: > I found the comment of function get_attgenerated(Oid relid, AttrNumber > attnum) seems wrong. > It seems the function is given the attribute number not the name. Thanks. Pushed. David

Re: [PATCH] Add section headings to index types doc

On 23.10.20 18:08, David G. Johnston wrote: On Fri, Oct 23, 2020 at 3:18 AM Jürgen Purtz > wrote: and add a link to the "CREATE INDEX" command from the chapter preamble. is the link necessary? I suppose it would make more sense to add it to the previous s