On July 3, 2015 06:21:09 PM Tom Lane wrote: > Jan de Visser <j...@de-visser.net> writes: > > Attached a new patch, rebased against the current head. Errors in > > pg_hba.conf and pg_ident.conf are now also noticed. > > > > I checked the documentation for pg_ctl reload, and the only place where > > it's explained seems to be runtime.sgml and that description is so > > high-level that adding this new bit of functionality wouldn't make much > > sense. > > BTW, it's probably worth pointing out that the recent work on the > pg_file_settings view has taken away a large part of the use-case for > this, in that you can find out more with less risk by inspecting > pg_file_settings before issuing SIGHUP, instead of SIGHUP'ing and > hoping you didn't break anything too nastily. Also, you can use > pg_file_settings remotely, unlike pg_ctl (though admittedly you > still need contrib/adminpack or something to allow uploading a > new config file if you're doing remote admin). > > I wonder whether we should consider inventing similar views for > pg_hba.conf and pg_ident.conf. > > While that's not necessarily a reason not to adopt this patch anyway, > it does mean that we should think twice about whether we need to add > a couple of hundred lines for a facility that's less useful than > what we already have.
Since you were the one proposing the feature, I'm going to leave it to you whether or not I should continue with this. I have no use for this feature; for me it just seemed like a nice bite-sized feature to get myself acquainted with the code base and the development process. As far as I'm concerned that goal has already been achieved, even though finalizing a patch towards commit (and having my name in the release notes ha ha) would be the icing on the cake. > > BTW, this version of this patch neglects to update the comments in > miscadmin.h, and it makes the return convention for > ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy > and inconsistency in the comments is a symptom of that. I didn't read it > in enough detail to say whether there are other problems. OK, miscadmin.h. I'll go and look what that's all about. And would it make sense to find a better solution for the ProcessConfigFileInternal return value (which is convoluted, I agree - I went for the solution with the least impact on existing code), or should I improve documentation? > > regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
