Greg Stark wrote:
MAX and MIN are single-parameter aggregate functions. LEAST and GREATEST are
two-parameter (though in postgres they could be defined for 3 and more
parameters) scalar functions.
If LEAST and GREATEST can accept any number of parameters, wouldn't it
make sense to code it like the
Tom Lane wrote:
But COALESCE is a special feature hard-wired into the parser. There's
no free lunch --- you pay for your extensibility somewhere.
That's what I'm suggesting: hard-wiring LEAST and GREATEST into the
parser. 7.5, maybe?
The question is: is it worth hard-wiring vs functions? (time
Tom Lane wrote:
create function greatest(anyelement, anyelement) returns anyelement as
'select case when $1>$2 then $1 else $2 end' language sql;
Any chance of this making it into 7.4's contrib? Maybe with enough
documentation to make it a tutorial for PostgreSQL's user functions?
You do have to
Christoph Haller wrote:
PostgreSQL 7.3.2
T1: begin; select * from foo for update;
T2: set STATEMENT_TIMEOUT = 1000; -- milliseconds
Seems like setting it to 1 (ms) emulates the NOWAIT condition better.
Can't set it to 0, though.
T2: select * from foo for update;
T2: ERROR: Query was cancelled.
I'm using Postgresql 7.02.
==
# explain select city.name, country.name from country, city
where city.country_id = country.country_id;
NOTICE: QUERY PLAN:
Hash Join (cost=8.85..16.76 rows=75 width=18)
-> Seq Scan on city (
On Wed, Jun 28, 2000 at 10:56:17AM -0400, Tom Lane wrote:
> Ang Chin Han <[EMAIL PROTECTED]> writes:
> If it was like that then a hash index wouldn't have been applicable
> anyway; hashes are only good for strict equality checks. If you want
> something that can do ord
On Wed, Jun 28, 2000 at 03:00:04AM -0400, Tom Lane wrote:
> Hash joins don't have anything to do with hash indexes.
> A hash join is a join that makes use of a temporary hashtable
> built on-the-fly *in memory* for that join.
Oh, I see.
> The planner could choose to use an indexscan on a hash i
I have a query which runs fast:
SELECT passwd FROM ticket WHERE name = ticket2name('test-006kdt') AND
survey_id = ticket2survey_id('test-006kdt');
But slows down to a crawl when I wrapped it in a function:
CREATE FUNCTION ticket2passwd(text) RETURNS text AS
'SELECT passwd FROM ticket WH
On Mon, Aug 07, 2000 at 10:58:27AM -0400, Tom Lane wrote:
> (I assume the lack of "survey_id =" here is just a cut-and-paste error?)
Yup. :)
> I think what you're getting bit by is that the optimizer doesn't
> recognize "var = function(param)" as being a potential indexscan clause.
> Does EXPLA
Apologies in advance for the length of this post, but this has
been bugging me for a week or so.
Consider a table with a primary key pk and a list of attributes a, b
and c:
Table t
pk a b c
---
1 1 1 1
2 1 2 3
: etc :
9998 1 1 1
2 1
On Wed, Aug 09, 2000 at 02:53:45PM +0800, Ang Chin Han wrote:
> The queries making use of these might be rewritten as:
> 1. select min(a) from t_sum; -- same as above,
> -- but we've less rows to scan
> 2. select cnt from t_sum where a = 1
On Wed, Aug 09, 2000 at 12:04:13PM -0400, Mark Volpe wrote:
> I have a table with a trigger that can potentially modify a row before it gets
> inserted or updated:
[snip]
> I have another table that tracks changes in the first table with rules:
AFAIK, rules get rewritten first, before triggers
12 matches
Mail list logo
