Re: GSoC 2018 - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: GSoC 2018
Date
Msg-id 20171215135217.GA14837@e733.localdomain
Whole thread Raw
In response to Re: GSoC 2018  (Stephen Frost <sfrost@snowman.net>)
Responses Re: GSoC 2018
Re: GSoC 2018
List 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

Attachment

pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] pgbench more operators & functions
Next
From: Maksim Milyutin
Date:
Subject: [HACKERS] wrong t_bits alignment in pageinspect