Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Let me give you some examples. We might someday have nested
> transactions, or transactions which can be resumed from the point of
> failure. We *might* want to be able to affect recovery behaviors, and we
> *might* want to do so with something like
> begin;
> update foo...
> update bar...
> <last update fails>
> set blah to blah
> update baz...
> update bar...
> <last update now succeeds>
> end;
Sure, once we have savepoints or nested transactions I would expect SET
to work like that. The "alternative 1" should better be phrased as
"SETs should work the same way as regular SQL commands do".
I agree with your comment that it would be useful to look closely at the
list of settable variables to see whether any of them need different
semantics. Here's the list of everything that can be SET after backend
start (some of these require superuser privilege to set, but that seems
irrelevant):
datestyle
timezone
XactIsoLevel
client_encoding
server_encoding
seed
session_authorization
enable_seqscan
enable_indexscan
enable_tidscan
enable_sort
enable_nestloop
enable_mergejoin
enable_hashjoin
ksqo
geqo
debug_assertions
debug_print_query
debug_print_parse
debug_print_rewritten
debug_print_plan
debug_pretty_print
show_parser_stats
show_planner_stats
show_executor_stats
show_query_stats
show_btree_build_stats
explain_pretty_print
stats_command_string
stats_row_level
stats_block_level
trace_notify
trace_locks
trace_userlocks
trace_lwlocks
debug_deadlocks
sql_inheritance
australian_timezones
password_encryption
transform_null_equals
geqo_threshold
geqo_pool_size
geqo_effort
geqo_generations
geqo_random_seed
sort_mem
vacuum_mem
trace_lock_oidmin
trace_lock_table
max_expr_depth
wal_debug
commit_delay
commit_siblings
effective_cache_size
random_page_cost
cpu_tuple_cost
cpu_index_tuple_cost
cpu_operator_cost
geqo_selection_bias
client_min_messages
default_transaction_isolation
dynamic_library_path
search_path
server_min_messages
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
> And btw, if we *are* going to put transaction semantics on all of our
> global variables (which is the context for starting this "SET"
> discussion, right? Is that really the context we are still in, even
> though you have phrased a much more general statement above?) then let's
> have the discussion on *HOW* we are going to accomplish that *BEFORE*
> deciding to make a semantic constraint on our language support.
Hardly necessary: we'll just make guc.c keep track of the
start-of-transaction values of all variables that have changed in the
current transaction, and restore them to that value upon transaction
abort. Doesn't seem like a big deal to me. We've got tons of other
code that does exactly the same sort of thing.
> Hmm, if we are going to use transaction semantics, then we should
> consider using our existing transaction mechanisms, and if we use our
> existing transaction mechanisms we should consider pushing these global
> variables into tables or in memory tables a la "temp tables".
Quite a few of the GUC settings are values that need to be set and used
during startup, before we have table access up and running. I do not
think that it's very practical to expect them to be accessed through
table access mechanisms.
> If we end up making changes and increasing constraints, then we should
> also expect some increased functionality as part of the scheme,
> specifically "SET extensibility".
It might well be a good idea to allow variables to be added to guc.c's
lists on-the-fly by the initialization routines of loadable modules.
But that's orthogonal to this discussion, IMHO.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
