Josh Berkus wrote:
Tom, Justin,
Um, not documenting it is probably not a good move for us, however putting
it at the end in a section marked Developer Focused or something similar
would probably have the right mix of messages. i.e. hands off + not a
performance tweak, etc.
So,
Josh Berkus wrote:
Tom,
Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
option that's supposed to let you turn off Inserting missing FROM clause for
table ...
I thought that patch was accepted 3 weeks ago? Is this just missing from
postgresql.conf.sample?
On Mon, 9 Jun 2003, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
option that's supposed to let you turn off Inserting missing FROM clause for
table ...
Bruce hasn't applied that patch yet. I believe
Nigel J. Andrews wrote:
On Mon, 9 Jun 2003, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
option that's supposed to let you turn off Inserting missing FROM clause for
table ...
Bruce hasn't
Justin Clift wrote:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
wal_debug is seldom used outside of Postgresql source development or unusual
system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be
Jan,
No, not documenting it IS a good move.
I couldn't disagree more. Undocumented options? Who are we, Microsoft?
If there's a button people will
press it, if there's a switch people will turn it on and if there's a
slot people will stick in whatever they have ... believe it or
Okay, separate documentation might work ;-)
Jan
Josh Berkus wrote:
Jan,
No, not documenting it IS a good move.
I couldn't disagree more. Undocumented options? Who are we, Microsoft?
If there's a button people will
press it, if there's a switch people will turn it on and if there's a
Tom,
I'm noticing re-namining of a lot of GUCs. As far as I can tell, the
re-naming is based on logical reasons -- for example, log_hostname is more
accurate that hostname_lookup -- but was a little surprised. We'd better
warn users who are upgrading
--
-Josh Berkus
Aglio Database
Tom,
Also, Autocommit seems to be gone from postgresql.conf.sample. Was this
intentional?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Josh Berkus [EMAIL PROTECTED] writes:
Also, Autocommit seems to be gone from postgresql.conf.sample. Was this
intentional?
Yes. It's toast ... didn't you see that flamewar a couple months ago?
regards, tom lane
---(end of
Tom,
Yes. It's toast ... didn't you see that flamewar a couple months ago?
Nope, missed it. There's enough traffic on this list that I ignore anything
that I'm not working on.
So are we eliminating the autocommit GUC entirely, or just from
postgresql.conf?
(I never used the setting,
Josh Berkus [EMAIL PROTECTED] writes:
So are we eliminating the autocommit GUC entirely, or just from
postgresql.conf?
Entirely --- putting it on the server side was a bad mistake, in
hindsight. The functionality is better provided on the client side.
(The GUC var does still physically
So are we eliminating the autocommit GUC entirely, or just from
postgresql.conf?
It's a client side feature now. Completely gone from the server.
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
Robert Treat [EMAIL PROTECTED] writes:
I think this was touched on before, but was there a final determination
of the ordering of the show all command?
SHOW ALL will remain alphabetical.
regards, tom lane
---(end of
Josh Berkus [EMAIL PROTECTED] writes:
Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
option that's supposed to let you turn off Inserting missing FROM clause for
table ...
Bruce hasn't applied that patch yet. I believe he's starting to catch
up the patch backlog
Tom, Justin,
Um, not documenting it is probably not a good move for us, however putting
it at the end in a section marked Developer Focused or something similar
would probably have the right mix of messages. i.e. hands off + not a
performance tweak, etc.
So, proposal:
1) wal_debug and the
Tom,
Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
option that's supposed to let you turn off Inserting missing FROM clause for
table ...
I thought that patch was accepted 3 weeks ago? Is this just missing from
postgresql.conf.sample?
--
-Josh Berkus
Aglio
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
wal_debug is seldom used outside of Postgresql source development or unusual
system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be documented at all.
Folks,
Attached is another order outline for the Postgresql.conf parameters, updated
for 7.4. Please examine it, and then give your opinions on the following:
1) Should enable_implicit_from go in the Version/Platform Compatibility
section where I have it now, or in CLIENT
On Thu, 2003-06-05 at 14:16, Josh Berkus wrote:
Rod,
4) Does anyone else have any comments on the proposed re-ordering?
Since we're painting a shed, does it make sense to put the items in
alphabetical order for each section?
I thought about that, yes. However, I find that most
Rod,
4) Does anyone else have any comments on the proposed re-ordering?
Since we're painting a shed, does it make sense to put the items in
alphabetical order for each section?
I thought about that, yes. However, I find that most items have a logical
order that is not alphabetical.
I kind of prefer the way things were grouped together in 7.2 vs. 7.3. If I
needed to check out connection information or look at query tuning flags,
they were all right next to each other and I didn't have to scroll back and
forth through the list. Luckily most of the topical variables share
Josh Berkus [EMAIL PROTECTED] writes:
wal_debug is seldom used outside of Postgresql source development or unusual
system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be documented at all. I cannot
I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.
---
Robert Treat wrote:
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
4) Does anyone else have
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
4) Does anyone else have any comments on the proposed re-ordering?
I think this was touched on before, but was there a final determination
of the ordering of the show all command? I'm hoping that will return
in the new order of the
4) Does anyone else have any comments on the proposed re-ordering?
Since we're painting a shed, does it make sense to put the items in
alphabetical order for each section?
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally
Josh Berkus [EMAIL PROTECTED] writes:
1) Are any additional changes expected for GUC.c before feature-freeze?
I'm still thinking of adding an am_superuser variable so that psql can
rely on the new ParameterStatus mechanism instead of explicit queries to
find out if you're superuser. But this
27 matches
Mail list logo
