will be the only
vendor to do so (though, this seems like a very MySQL-ish thing to do
so maybe not just Postgres)
take care,
Anthony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, October 14, 2005 3:21 AM
To: Anthony Molinaro
Cc: Greg Stark; Scot
or them to be workin
on...
Regards,
Anthony
-Original Message-----
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 13, 2005 3:17 PM
To: Anthony Molinaro
Cc: Scott Marlowe; Greg Stark; Stephan Szabo; Rick Schumeyer;
pgsql-sql@postgresql.org
Subject: Re: [SQL] pg, mys
Well...
An additional gripe is that this isn't a good feature (standard or not).
Oracle doesn't do it. Db2 doesn't do it. I strongly suggest you guys
don't
do it.
If you wanna do the optimizations under the covers, cool, but I can't
imagine how this would be useful other than for saving some typ
Greg,
"
You would prefer:
select user_id,
any(username) as username, any(firstname) as firstname,
any(lastname) as lastname, any(address) as address,
any(city) as city, any(street) as street, any(phone) as phone,
any(last_update) as last_update, any(last_login) as l
group by
are:
1. constants and deterministic functions
2. scalar subqueries
3. window functions
1 - because the value is same for each row
2&3 - because they are evaluated after the grouping takes place
regards,
Anthony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PR
:[EMAIL PROTECTED]
Sent: Wednesday, October 12, 2005 11:43 PM
To: Anthony Molinaro
Cc: Tom Lane; Greg Stark; Scott Marlowe; Stephan Szabo; Rick Schumeyer;
pgsql-sql@postgresql.org
Subject: Re: [SQL] pg, mysql comparison with "group by" clause
"Anthony Molinaro" <[EMAIL P
Tom,
Don't do it man...
It's not the same. The standard has it wrong (that or I misunderstood
your
explanation). But this statement:
> you shouldn't have to explicitly list the other columns from that
> table --- they are guaranteed to have unique values per group anyway
...is way off.
By c
> I don't see why you think people stumble on this by accident. I think
it's
> actually an extremely common need.
I can't imagine how that's a common need at all.
It makes no sense.
When you add an additional column in the select, it must be included in
the group by as it changes the meaning of
> Not always, but I'd rather get the right answer with difficulty than
the
wrong one with ease. :)
agreed.
I made it a point to mention this so called "feature" in my book.
This is a bug they never fixed and they decided to call it a feature.
It is, imo, *ridiculous*.
Regards,
Anthony
You're 100% correct, this is a bug in mysql.
Sadly, they tout this as a feature!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Schumeyer
Sent: Tuesday, October 11, 2005 5:12 PM
To: pgsql-sql@postgresql.org
Subject: [SQL] pg, mysql comparison with "
Jeziel,
there are a couple techniques you can try, two I
like are set difference and anti-joins.
here’s the set diff:
select id
from messages
except
select id
from usermessages
that will returns all id from messages not in usermessages
if ID is indexed on both
ns don't get to production ;)
Regards,
Anthony
-Original Message-
From: Daryl Richter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 27, 2005 11:35 AM
To: Anthony Molinaro
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] how to do 'deep queries'?
Anthony Molinaro wrote:
&
rds,
Anthony
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Daryl Richter
Sent: Tuesday, September 27, 2005 9:24 AM
To: pgsql-sql@postgresql.org
Subject: Re: [SQL] how to do 'deep queries'?
Anthony Molinaro wrote:
> that query is 100% correct.
&
that query is 100% correct.
it’s just an equijoin (a type of
inner join) between 3 tables.
the syntax you show is how queries should
be written and is more
representative of what a joins between
relations really are:
Cartesian products with filters applied
the ansi syntax, the
Michael,
You practically solved it yourself in the subject of the email ;)
select replace('abcd','b','') from your_table;
Hope that helps,
Anthony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Michael Höller"
Sent: Thursday, September 08, 2005 5:
ht be just fine.
10k rows should not be a problem for either method,
assuming you have an index on statusid and bill_id.
Give it a spin and update this thread.
Regards,
Anthony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005 8:08 AM
Amit,
You say "I want to know how much time it took for a bill to be
accepted after it was submitted"
So, do you want between 10 and 40, not 10 and 20?
I assume you meant 10 and 40.
Ok, there's a few approaches to your questions, first
To get "how much time it took for a bill to be accepted afte
17 matches
Mail list logo
