Rich:
On Thu, Aug 19, 2021 at 6:59 PM Rich Shepard wrote:
> On Thu, 19 Aug 2021, Rob Sargent wrote:
> > Yeah, but my quibble is the the table you described up-thread. Your
> > contact table contains next_contact? I think that column should be
> > normalized out.
> Why should I have a separate tab
Hi all,
Since pg13 support trusted extension, so I changed control file of bloom and make it trusted. The test provided by pg13 for bloom passed using normal user. But when i tried to drop extension, it failed.
test=> create extension bloom;CREATE EXTENSIONtest=> drop extension bloom;ERROR: mu
On Fri, 20 Aug 2021, Francisco Olarte wrote:
Is your next_contact really dependent on the contact record (
person+contact_date? ).
Francisco,
Yes.
I mean, your tables seem CRM like. You stated next_contact for old
contacts is not interesting. It seems next_contact is associated just
by a pe
Team,
I have a pg 10 cluster with a master and two hot-standby nodes. There is a
requirement for a manual failover (nodes switching the roles) at will. This is
a vanilla 3 node PG cluster that was built with WAL archiving (central
location) and streaming replication to two hot standby nodes. T
On Thu, Aug 19, 2021 at 11:41 AM Julien Rouhaud wrote:
>
> The value you see on pg_settings is the one that's selected for your
> current connection, based on the database/role you used.
>
> You can use \drds in psql to see the various configurations, or query
> the pg_db_role_setting table.
>
Th
"Li EF Zhang" writes:
> Since pg13 support trusted extension, so I changed control file of bloom and
> make it trusted.
The fact that you can edit the file that way doesn't make it a supported
case.
regards, tom lane
Hi Tom,
thank you very much for your reply. Actually, I was assuming all these
regular expressions are based on the same core implementation.
Interestingly, this doesn't seem to be true...
I am also surprised that you say the (\1)+ subpattern is computationally
expensive. Regular expressions are
Thank you very much for all your proposals!
Ingolf
==
Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht
Dortmund, HRB 14952 - Geschäftsführer: Detlef Eppig - Vorsitzender des
Aufsichtsrats: France
"Markhof, Ingolf" writes:
> thank you very much for your reply. Actually, I was assuming all these
> regular expressions are based on the same core implementation.
They are not. There are at least three fundamentally different
implementation technologies (DFA, NFA, hybrid). Friedl's "Mastering
> On Aug 20, 2021, at 9:52 AM, Tom Lane wrote:
>
> "a*" is easy. "(a*)\1" is less easy --- if you let the a* consume the
> whole string, you will not get a match, even though one is possible.
> In general, backrefs create a mess in what would otherwise be a pretty
> straightforward concept :-
On Fri, Aug 20, 2021 at 12:32 PM Mark Dilger
wrote:
>
> The following queries take radically different time to run:
>
Unbounded ranges seem like a problem. Seems worth trying a range from 1 to
N where you play around with N to find your optimum
performance/functionality tradeoff. {1,20} is like
> On Aug 20, 2021, at 12:51 PM, Miles Elam wrote:
>
> Unbounded ranges seem like a problem.
Seems so. The problem appears to be in regcomp.c's repeat() function which
handles {1,SOME} differently than {1,INF}
> Seems worth trying a range from 1 to N where you play around with N to find
>
12 matches
Mail list logo
