Committed.
--
nathan
Thanks to Álvaro and Tom for reviewing.
On Tue, Dec 03, 2024 at 01:01:29PM -0500, Tom Lane wrote:
> +/* special must-be-first options for dispatching to various subprograms */
> +typedef enum Subprogram
> +{
> + SUBPROGRAM_CHECK,
> + ... etc
>
> "Subprogram" doesn't quite seem like the ri
Nathan Bossart writes:
> Here's what I have staged for commit.
In addition to Alvaro's comments:
+/* special must-be-first options for dispatching to various subprograms */
+typedef enum Subprogram
+{
+ SUBPROGRAM_CHECK,
+ ... etc
"Subprogram" doesn't quite seem like the right name
On 2024-Dec-03, Nathan Bossart wrote:
> +Subprogram
> +parse_subprogram(const char *name)
> +{
Please add a comment atop this function. Also, I don't think it should
go at the end of the file; maybe right after main() is a more
appropriate location?
> +/* special must-be-first options for dispa
Here's what I have staged for commit. I didn't like how v4 added the ERROR
to ParseLongOption(), so in v5 I've moved it to the callers of
ParseLongOption(), which is where the existing option validation lives.
This results in a bit of code duplication, but IMHO that's better than
adding nonobvious
On Mon, Aug 26, 2024 at 11:43 AM Nathan Bossart
wrote:
> On Sun, Aug 25, 2024 at 01:14:36PM -0400, Greg Sabino Mullane wrote:
> > I'm not happy about making this and the const char[] change their
> structure
> > based on the ifdefs - could we not just leave forkchild in? Their usage
> is
> > alre
On Sun, Aug 25, 2024 at 01:14:36PM -0400, Greg Sabino Mullane wrote:
> I'm not happy about making this and the const char[] change their structure
> based on the ifdefs - could we not just leave forkchild in? Their usage is
> already protected by the ifdefs in the calling code.
Here's an attempt a
I'm not opposed to this new method, as long as the error code improves. :)
+typedef enum Subprogram
+{
+ SUBPROGRAM_CHECK,
+ SUBPROGRAM_BOOT,
+#ifdef EXEC_BACKEND
+ SUBPROGRAM_FORKCHILD,
+#endif
I'm not happy about making this and the const char[] change their structure
based on the ifdefs - coul
On Wed, Jun 19, 2024 at 10:58:02AM -0500, Nathan Bossart wrote:
> On Wed, Jun 19, 2024 at 05:34:52PM +0200, Peter Eisentraut wrote:
>> I'm not really sure all this here is worth solving. I think requiring
>> things like --single or --boot to be first seems ok, and the alternatives
>> just make thi
On Wed, Jun 19, 2024 at 05:34:52PM +0200, Peter Eisentraut wrote:
> I'm not really sure all this here is worth solving. I think requiring
> things like --single or --boot to be first seems ok, and the alternatives
> just make things more complicated.
Yeah, I'm fine with doing something more like
On 19.06.24 16:04, Nathan Bossart wrote:
What about just inlining --version and --help e.g.
else if (strcmp(argv[i], "--version") == 0 || strcmp(argv[i], "-V") == 0)
{
fputs(PG_BACKEND_VERSIONSTR, stdout);
exit(0);
}
I'm fine with being more persnickety about the other options; they
On Tue, Jun 18, 2024 at 09:42:32PM -0400, Greg Sabino Mullane wrote:
> If I am reading your patch correctly, we have lost the behavior of least
> surprise in which the first "meta" argument overrides all others:
>
> $ bin/postgres --version --boot --extrastuff
> postgres (PostgreSQL) 16.2
Right,
If I am reading your patch correctly, we have lost the behavior of least
surprise in which the first "meta" argument overrides all others:
$ bin/postgres --version --boot --extrastuff
postgres (PostgreSQL) 16.2
What about just inlining --version and --help e.g.
else if (strcmp(argv[i], "--versio
On Wed, Jun 05, 2024 at 11:38:48PM -0400, Greg Sabino Mullane wrote:
> On Wed, Jun 5, 2024 at 3:18 PM Nathan Bossart
> wrote:
>> Could we remove the requirement that --single must be first? I'm not
>> thrilled about adding a list of "must be first" options that needs to stay
>> updated, but given
On Wed, Jun 5, 2024 at 3:18 PM Nathan Bossart
wrote:
> Could we remove the requirement that --single must be first? I'm not
> thrilled about adding a list of "must be first" options that needs to stay
> updated, but given this list probably doesn't change too frequently, maybe
> that's still bet
On Wed, Jun 05, 2024 at 02:51:05PM -0400, Greg Sabino Mullane wrote:
> Please find attached a quick patch to prevent this particularly bad error
> message for running "postgres", when making the common mistake of
> forgetting to put the "--single" option first because you added an earlier
> arg (es
Please find attached a quick patch to prevent this particularly bad error
message for running "postgres", when making the common mistake of
forgetting to put the "--single" option first because you added an earlier
arg (esp. datadir)
Current behavior:
$ ~/pg/bin/postgres -D ~/pg/data --single
202
17 matches
Mail list logo
