-Original Message-
From: Fernando Nasser
Hiroshi Inoue wrote:
We can't do that. Accordingly to the SQL if you are user HIROSHI
and write SELECT * FROM a; the table is actually HIROSHI.a.
This must work for people who are using SQL-schemas in their databases
or we
-Original Message-
From: Tom Lane
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that "timeout" is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than
A more serious objection is that this will break client applications
that know about the pg_aggregate table. However, 7.3 is already going
to force a lot of reprogramming of clients that inspect system tables,
because of the addition of namespaces. Restructuring pg_aggregate
doesn't seem
AFAICS, making them exact would not improve the planning estimates
at all, because there are too many other sources of error. We have
approximate stats already via vacuum/analyze statistics gathering.
What happens if someone deletes 75% of a table?
What happens if someone imports 30 times
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
How about putting a note in the 7.3 release that tells them not to rely on
sequential attnums in tn pg_attribute anymore. That should make it easier
to implement column dropping in the future?
That seems like pure speculation to me, if not
Hiroshi Inoue wrote:
-Original Message-
From: Tom Lane
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
On Sat, 6 Apr 2002, Bruce Momjian wrote:
What's wrong with simply issueing set query_timeout
command just before every query ?
You could do that, but we also imagine cases where people would want to
set a timeout for each query in an entire session.
One approach might be for the
Tom Lane writes:
Why shouldn't aggregate functions have entries in pg_proc? Then one
search would cover both possibilities, and we could eliminate some
duplicate code in the parser.
Furthermore, we could make the new function privileges apply to aggregates
as well.
--
Peter Eisentraut
Jessica Perry Hekman wrote:
On Sat, 6 Apr 2002, Bruce Momjian wrote:
What's wrong with simply issueing set query_timeout
command just before every query ?
You could do that, but we also imagine cases where people would want to
set a timeout for each query in an entire session.
Bruce Momjian [EMAIL PROTECTED] writes:
One approach might be for the interface to take care of setting the query
timeout before each query, and just ask the backend to handle timeouts
per-query. So from the user's perspective, session-level timeouts would
exist, but the backend would not
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Why shouldn't aggregate functions have entries in pg_proc?
Furthermore, we could make the new function privileges apply to aggregates
as well.
Good point. Another thing that would fall out for free is that the
aggregate
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One approach might be for the interface to take care of setting the query
timeout before each query, and just ask the backend to handle timeouts
per-query. So from the user's perspective, session-level timeouts would
exist, but the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We do have on_shmem_exit and on_proc_exit function call queues. Seems
we will need SET to create a queue of function calls containing previous
values of variables SEt in multi-statement transactions. If we execute
the queue in
Bruce Momjian [EMAIL PROTECTED] writes:
We do have on_shmem_exit and on_proc_exit function call queues. Seems
we will need SET to create a queue of function calls containing previous
values of variables SEt in multi-statement transactions. If we execute
the queue in last-in-first-out order,
Bruce Momjian [EMAIL PROTECTED] writes:
Ewe, I was hoping for something with zero overhead for the non-SET case.
Well, a function call and immediate return if no SET has been executed
in the current xact seems low enough overhead to me. We'll just keep
a flag showing whether there's anything
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Ewe, I was hoping for something with zero overhead for the non-SET case.
Well, a function call and immediate return if no SET has been executed
in the current xact seems low enough overhead to me. We'll just keep
a flag showing
Tom Lane wrote:
Note: I am now pretty well convinced that we *must* fix SET to roll back
to start-of-transaction settings on transaction abort. If we do that,
at least some of the difficulty disappears for JDBC to handle one-shot
timeouts by issuing SETs before and after the target query
Tom Lane writes:
Note: I am now pretty well convinced that we *must* fix SET to roll back
to start-of-transaction settings on transaction abort. If we do that,
at least some of the difficulty disappears for JDBC to handle one-shot
timeouts by issuing SETs before and after the target query
Peter Eisentraut [EMAIL PROTECTED] writes:
Can we all compromise on that?
No.
Oh dear...
I agree that there may be some variables that must be rolled back, or
where automatic reset on transaction end may be desirable (note that these
are two different things), but for some variables it's
We had discussed a while ago that it might be a good idea to compile with
debugging symbols by default, at least when using GCC.
A tricky questions is what to do with the --enable-debug option. For GCC
it would become --disable-debug (i.e., remove -g from CFLAGS), but I'm not
sure we'd need
Tom Lane writes:
I didn't say transaction specific. I said that if you do a SET inside
a transaction block, and then the transaction is aborted, the effects of
the SET ought to roll back along with everything else you did inside
that transaction block. I'm not seeing what the argument is
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Hiroshi Inoue wrote:
-Original Message-
From: Tom Lane
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next
22 matches
Mail list logo
