> -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
> > > > aut
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
>
>
> I guess it's a matter of definition: Do you consider SET variables
> database state or session metadata?
Session metadata IMHO. If there are(would be) database state
variables we should introduce another co
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I consider SET variables metadata that are not affected by transactions.
Why? Again, the fact that historically they've not acted that way isn't
sufficient reason for me.
> I should be able to change my mind about my session preferences in the
> mi
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
> 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
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 variable
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 quer
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 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 show
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
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 o
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 qu
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
> >> e
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 type
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 woul
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
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
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 i
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 l
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 no
> 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 3
> 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 se
> -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
> -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 thei
24 matches
Mail list logo
