On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander <mag...@hagander.net>

> On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Magnus Hagander <mag...@hagander.net> writes:
>> > Here's another attempt at moving this one forward. Basically this adds a
>> > new GucSource being GUC_S_CLIENT_EARLY. It now runs through the
>> parameters
>> > once before CheckMyDatabase, with source set to GUC_S_CLIENT_EARLY. In
>> this
>> > source, *only* parameters that are flagged as GUC_ALLOW_EARLY will be
>> set,
>> > any other parameters are ignored (without error). For now, only the
>> > ignore_connection_restriction is allowed at this stage. Then it runs
>> > CheckMyDatabase(), and after that it runs through all the parameters
>> again,
>> > now with the GUC_S_CLIENT source as usual, which will now process all
>> > other  variables.
>> Ick.  This is an improvement over the other way of attacking the problem?
>> I do not think so.
> Nope, I'm far from sure that it is. I just wanted to show what it'd look
> like.
> I personally think the second patch (the one adding a parameter to
> BackendWorkerInitializeConnection) is the cleanest one. It doesn't solve
> Andres' problem, but perhaps that should be the job of a different patch.

FWIW, I just realized that thue poc patch that adds the GUC also breaks a
large part of the regression tests. As a side-effect of it breaking how
DateStyle works. That's obviously a fixable problem, but it seems not worth
spending time on if that's not the way forward anyway.

Andres, do you have any other ideas of directions to look that would make
you withdraw your objection? I'm happy to try to write up a patch that
solves it in a way that everybody can agree with. But right now it seems to
be stuck between one way that's strongly objected to by you and one way
that's strongly objected to by Tom. And I'd rather not have that end up
with not getting the problem solved at all for *any* of the usecases...

 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Reply via email to