Bruce Momjian [EMAIL PROTECTED] writes:
I don't think we can remove -o behavior during beta because it will
affect people using -S in startup scripts.
That was *not* the proposal under discussion. The proposal was to
warn people in the 7.2 documentation that we plan to remove -o in 7.3.
Bruce Momjian [EMAIL PROTECTED] writes:
Would someone give me a status on this?
I don't think we need any code changes. If we decide to deprecate -o
(or anything else), it's just a documentation change. So we can argue
about it during beta ...
If we notify of the impending
Bruce Momjian [EMAIL PROTECTED] writes:
Would someone give me a status on this?
I don't think we need any code changes. If we decide to deprecate -o
(or anything else), it's just a documentation change. So we can argue
about it during beta ...
If we notify of the impending deprecation now,
Bruce Momjian [EMAIL PROTECTED] writes:
Would someone give me a status on this?
I don't think we need any code changes. If we decide to deprecate -o
(or anything else), it's just a documentation change. So we can argue
about it during beta ...
If we notify of the impending
Bruce Momjian [EMAIL PROTECTED] writes:
I don't think we can remove -o behavior during beta because it will
affect people using -S in startup scripts.
That was *not* the proposal under discussion. The proposal was to
warn people in the 7.2 documentation that we plan to remove -o in 7.3.
Would someone give me a status on this?
---
Hi all,
There seem to be a few namespace conflicts for the options of postgres
and postmaster. The one's I could identify from the man pages are :
-i -N -o -p -S -s
Hi all,
There seem to be a few namespace conflicts for the options of postgres
and postmaster. The one's I could identify from the man pages are :
-i -N -o -p -S -s
If we are going to deprecate -o, then we'll need to make sure we also
introduce replacement names where these conflicts are.
On Sun, Sep 30, 2001 at 12:54:25AM +0200, Peter Eisentraut wrote:
Tom Lane writes:
While that's not a fatal problem, I could imagine *much* more serious
misbehavior from inconsistent settings of some GUC parameters. Since
backends believe that these parameters have PGC_POSTMASTER
Marko Kreen [EMAIL PROTECTED] writes:
I wonder whether we should retire -o.
How about putting -o stuff after -p? That way only postmaster
code can set PGC_POSTMASTER options for a backend, no way for
user to mess up. ATM this would break -o -F tho'.
Indeed. If we're going to force people
Marko Kreen [EMAIL PROTECTED] writes:
I wonder whether we should retire -o.
How about putting -o stuff after -p? That way only postmaster
code can set PGC_POSTMASTER options for a backend, no way for
user to mess up. ATM this would break -o -F tho'.
Not sure what you are suggesting
On Sun, Sep 30, 2001 at 02:13:34PM -0400, Bruce Momjian wrote:
Marko Kreen [EMAIL PROTECTED] writes:
I wonder whether we should retire -o.
How about putting -o stuff after -p? That way only postmaster
code can set PGC_POSTMASTER options for a backend, no way for
user to mess up.
Marko Kreen [EMAIL PROTECTED] writes:
I am suggesting this.
[ code snipped ]
Okay, that would mean that -o '-S nnn' still works, but -o -F
doesn't.
But ... the thing is, there is no reason for -o to exist anymore other
than backwards compatibility with existing startup scripts. -o doesn't
do
Tom Lane wrote:
snip
I wonder whether we should retire -o. Or change it so that the
postmaster parses the given options for itself (consequently adjusting
its copies of GUC variables) instead of passing them on to backends
for parsing at backend start time.
Retiring -o would seem like a
Justin Clift [EMAIL PROTECTED] writes:
Retiring -o would seem like a good idea.
That was what I was thinking too. I can think of ways to reimplement
-o options so that they work safely ... but is it worth the trouble?
AFAICS, -o options confuse both people and machines, and have no
redeeming
I have just noticed a flaw in the handling of -o backend-options
postmaster parameters. To wit: although these options will be passed
to all backends launched by the postmaster, they aren't passed to
checkpoint, xlog startup, and xlog shutdown subprocesses (everything
that goes through
15 matches
Mail list logo
