From: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GSoC 2018 |
Date: | 2017-12-15 13:52:18 |
Message-ID: | 20171215135217.GA14837@e733.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Stephen,
> synchronous_commit isn't the same as synchronous_standby_names ...
What about synchronous_standby_names? Logical replication ignores it and
doesn't wait for ack's from replicas or something?
> What might be interesting is seeing if Logical Replication could be
> added to Patroni as an option and then building on that.. Having
> someone involved in the Patroni project would be the right way to go
> about proposing that though to see what they think of it. That would
> also be much more sensible as a GSoC project, since it'd be an addition
> to an existing project and not more-or-less starting a whole new
> project.
Completely agree, this project can be an improvement for Stolon (or
Patroni, but I personally never tested or used it, also I got a feeling
that Google guys will prefer a project that is written in Go). This
would make much more sense.
> Wouldn't it make more sense to have something like what we have for
> JSONB where there's operators that are used to pull out specific fields
> instead of generated pl/pgsql procedures..?
I don't see why we can't have both procedures and operators like:
```
x -> 'field1' -- returns int
x ->> 'field2' -- returns string
```
The reason why some users may prefer procedures to operators is
that it's easy to make a typo in a field name. Procedures are safer in
this regard.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Maksim Milyutin | 2017-12-15 13:53:41 | [HACKERS] wrong t_bits alignment in pageinspect |
Previous Message | Teodor Sigaev | 2017-12-15 13:47:41 | Re: [HACKERS] pgbench more operators & functions |