raised if the timeout is
exceeded. Which, when I think about it, is probably good behavior --> it
allows me to distinguish between (1) a query that completed and returned no
records and (2) a query that aborted because it exceeded the timeout.
Thanks to all for the assist.
Bill Eaton
>> I want to allow some queries for my users to run for a prescribed period
of
>> time and kill them if they go over time. Is there a good way to do this?
> set statement_timeout perhaps?
Ooh. I like that. It would be absolutely brilliant if I could figure out how
to get it to work with ADO and t
ow the best way to do it. pgAdmin
allows queries to be killed. How does it do it?
Thanks in advance,
Bill Eaton
Thousand Oaks, CA
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
On Wed, 11 Oct 2006, Bill Eaton wrote:
I just notice that multiple inputs to aggregates are allowed in the
upcoming 8.2 release. This gives me a great incentive to play with
the beta and upgrade from 8.0.
One question remains: how about multiple outputs? Can I have a ROW as
a return
t it's not that easy to remember
either. And if you're already
> doing a lot of work to tease out the x and y points from various
tables, it simplifies your query
> if you can do a function call.
>
> I can't tell from what have read about user defined functions and
user
you're already doing a lot of work to tease out the x and y
points from various tables, it simplifies your query if you can do a
function call.
I can't tell from what have read about user defined functions and user
defined aggregates whether this kind of function is possible.
Bil
played search path was
"bar,beam,truss"
but the search path should really have been
bar, beam, truss
Once I changed that and reconnected to the database, everything went back to
what I expected. I couldn't have sorted it all out without the logging,
which I h
ables behind the scenes to figure out all
of the info on tables and field names, etc.
Since dropping the schema, the database, and even the "postgres" maintenance
database doesn't fix the problem, I was wondering if something could be
frelled up in template0 or templ
eSQL, according to the documentation.
Is there any corrupted information that might be stored in the templates
(template0 template1) that would account for this problem? Could it be a bug
in pgadmin?
Bill Eaton
Southern California
---(end of broadcast)--
