enable_constraint_exclusion GUC name

pgman wrote:

Is enable_constraint_exclusion the proper name for this feature? I know
we have enable* in the optimizer settings, but that naming seems
unfortunate in that we should have just called it hash_join and it could
be enabled/disabled.

I am thinking we should just call it constraint_exclusion.

So, given the silence on this, I assume people think we should rename
this before beta starts.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

I am thinking we should just call it constraint_exclusion.

So, given the silence on this, I assume people think we should rename
this before beta starts.

Well it depends either one seems correct per the postgresql.conf. For
example enable_seqscan, or "add"_missing_from_clause.

It seems that if the postgresql.conf parameter is actually causing a
different behavior we tend to note the behavior in the prefix (thus
enable/add) but that if it is more general we done (thus log_) .

I don't care either way but it seemed something to note before the
decision was made.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Bruce Momjian <pgman@candle.pha.pa.us> writes:

pgman wrote:

Is enable_constraint_exclusion the proper name for this feature? I know
we have enable* in the optimizer settings, but that naming seems
unfortunate in that we should have just called it hash_join and it could
be enabled/disabled.

I am thinking we should just call it constraint_exclusion.

So, given the silence on this, I assume people think we should rename
this before beta starts.

Or that they think it might as well be left alone. I would like to
think that the parameter will have a very finite lifespan anyway;
if it's still there in 8.2, it'll be because we didn't get cached
plan updating done, and I hope that will not be the case.

regards, tom lane

Joshua D. Drake wrote:

I am thinking we should just call it constraint_exclusion.

So, given the silence on this, I assume people think we should rename
this before beta starts.

Well it depends either one seems correct per the postgresql.conf. For
example enable_seqscan, or "add"_missing_from_clause.

It seems that if the postgresql.conf parameter is actually causing a
different behavior we tend to note the behavior in the prefix (thus
enable/add) but that if it is more general we done (thus log_) .

I don't care either way but it seemed something to note before the
decision was made.

I thought about that, but is seems all our booleans could logically fall
into the category of being enabled/disabled. For add_missing_from, the
add word is so people realize that it is really _adding_ to the FROM
list, so I see it as different.

Anyway, change committed. I can always change it back if people change
their mind.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I thought about that, but is seems all our booleans could logically fall
into the category of being enabled/disabled. For add_missing_from, the
add word is so people realize that it is really _adding_ to the FROM
list, so I see it as different.

Anyway, change committed. I can always change it back if people change
their mind.

I suggest that the rule you've been (unconsciously) following is the
following: parameters that form a verb phrase do not need an enable_ prefix.
But parameters that form a noun phrase do or else they sound strange.

Put another way, "all boolean parameters are verb phrases; if they're not then
turn them into a verb phrase by prepending a verb like `enable'"

I see a couple exceptions (debug_assertions, geqo) but mostly they seem to
follow this pattern.

I'm not sure that's a bad rule. Verbs sound nice when you read them:

show_parser_stats true
enable_hashjoin true

Nouns sound stranger and more awkward:

geqo true
parser_stats true
hashjoin true

--
greg

Greg Stark wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I thought about that, but is seems all our booleans could logically fall
into the category of being enabled/disabled. For add_missing_from, the
add word is so people realize that it is really _adding_ to the FROM
list, so I see it as different.

Anyway, change committed. I can always change it back if people change
their mind.

I suggest that the rule you've been (unconsciously) following is the
following: parameters that form a verb phrase do not need an enable_ prefix.
But parameters that form a noun phrase do or else they sound strange.

Put another way, "all boolean parameters are verb phrases; if they're not then
turn them into a verb phrase by prepending a verb like `enable'"

I see a couple exceptions (debug_assertions, geqo) but mostly they seem to
follow this pattern.

I'm not sure that's a bad rule. Verbs sound nice when you read them:

show_parser_stats true
enable_hashjoin true

Nouns sound stranger and more awkward:

geqo true
parser_stats true
hashjoin true

Interesting analysis. No verb in there.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Greg Stark wrote:

show_parser_stats true
enable_hashjoin true

Nouns sound stranger and more awkward:

geqo true
parser_stats true
hashjoin true

Interesting analysis. No verb in there.

Note that the verb isn't always the same and what verb is chosen helps someone
understand what the server will do.

show_parser_stats is going to "show" something.
add_missing_from is going to "add" something.

So what will standards_compliant_strings make the server *do*?

It's going to ignore backslash escapes. Perhaps the option should be something
like "interpret_nonstandard_string_escapes" or something like that.

I actually don't really like "interpret" but I can't think of anything else at
the moment.

--
greg

Greg Stark wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Greg Stark wrote:

show_parser_stats true
enable_hashjoin true

Nouns sound stranger and more awkward:

geqo true
parser_stats true
hashjoin true

Interesting analysis. No verb in there.

Note that the verb isn't always the same and what verb is chosen helps someone
understand what the server will do.

show_parser_stats is going to "show" something.
add_missing_from is going to "add" something.

So what will standards_compliant_strings make the server *do*?

It's going to ignore backslash escapes. Perhaps the option should be something
like "interpret_nonstandard_string_escapes" or something like that.

I actually don't really like "interpret" but I can't think of anything else at
the moment.

Ah, Peter renamed it to:

standard_conforming_strings

so what is does is "conform"?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073