On fre, 2009-08-21 at 20:07 -0400, Tom Lane wrote:
As of SQL99 it's supposed to be legal if you're grouping by a primary key
(or some other cases where the other columns can be proved functionally
dependent on the grouping columns, but that's the most useful one).
We haven't got round to
Dear friends,
I have been using PostgreSQL since 6.3 releases and I am a real fan.
Of course, I never use nor trust MySQL to deliver data.
Now I use Drupal 6.3 with PostgreSQL 8.4.
I loose a lot of time correcting Drupal SQL.
You may be interested in my developer feedback.
I gathered some
This page gathers most frequent problems that Drupal users and
developers encounter when using PostgreSQL.
I would be delighted to have your feedback.
Could some issues reasonably be fixed for a better Drupal support?
Well I doubt we would do anything to copy MySQL. However Drupal has
On Fri, 21 Aug 2009 18:22:41 +0200
Jean-Michel Pouré j...@poure.com wrote:
I gathered some real examples here: Guidelines for writing MySQL and
PostgreSQL compliant SQL = http://drupal.org/node/14
This page gathers most frequent problems that Drupal users and
developers encounter when
Jean-Michel Pour? wrote:
-- Start of PGP signed section.
Dear friends,
I have been using PostgreSQL since 6.3 releases and I am a real fan.
Of course, I never use nor trust MySQL to deliver data.
Now I use Drupal 6.3 with PostgreSQL 8.4.
I loose a lot of time correcting Drupal SQL.
On Fri, 2009-08-21 at 12:50 -0400, Bruce Momjian wrote:
I show multi-value INSERT was added in PG 8.2, not 8.4, * Add
support for multiple-row VALUES clauses, per SQL standard (Joe, Tom),
http://drupal.org/node/68.
I am confused because I thought Drupal worked with Postgres, but
Joshua D. Drake wrote:
This page gathers most frequent problems that Drupal users and
developers encounter when using PostgreSQL.
I would be delighted to have your feedback.
Could some issues reasonably be fixed for a better Drupal support?
Well I doubt we would do anything to copy
2009/8/21 Andrew Dunstan and...@dunslane.net:
Since you haven't shown us what page this refers to, I at least am totally
in the dark about what is being discussed.
It was in the original post
http://drupal.org/node/14
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via
Greg Stark wrote:
2009/8/21 Andrew Dunstan and...@dunslane.net:
Since you haven't shown us what page this refers to, I at least am totally
in the dark about what is being discussed.
It was in the original post
http://drupal.org/node/14
Darn. Our mail system sucks badly.
2009/8/21 Jean-Michel Pouré j...@poure.com:
Dear friends,
I have been using PostgreSQL since 6.3 releases and I am a real fan.
Of course, I never use nor trust MySQL to deliver data.
Now I use Drupal 6.3 with PostgreSQL 8.4.
I loose a lot of time correcting Drupal SQL.
You may be
Jean-Michel,
Thank you for doing this!
I've registered for the Drupal site so that I can fix and/or expand some
of your items.
People who know Drupal better than me should add to them.
If you want to discuss Drupal PostgreSQL again, please post on the
pgsql-advocacy list or the pgsql-php
Josh Berkus j...@agliodbs.com writes:
BTW, why don't we have a multi-argument version of CONCAT()?
Why wouldn't people use the SQL-standard || operator instead?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
I've registered for the Drupal site so that I can fix and/or expand
some
of your items.
Thanks. I corrected the index on dual fields page.
If you want to discuss Drupal PostgreSQL again, please post on the
pgsql-advocacy list or the pgsql-php mailing lists. pgsql-hackers
isn't
the best
On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
BTW, why don't we have a multi-argument version of CONCAT()?
Why wouldn't people use the SQL-standard || operator instead?
Because by default, MySQL uses that as, get this, logical OR.
Cheers,
David Fetter da...@fetter.org writes:
On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
BTW, why don't we have a multi-argument version of CONCAT()?
Why wouldn't people use the SQL-standard || operator instead?
Because by default, MySQL uses
On 8/21/09 3:17 PM, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
BTW, why don't we have a multi-argument version of CONCAT()?
Why wouldn't people use the SQL-standard || operator instead?
Jean-Michel Pouré wrote:
BTW, why don't we have a multi-argument version of CONCAT()? In 8.4,
it
would be possible ... I should add it to mysqlcompat library.
yes. In PostgreSQL core ...
No. That is exactly where it shouldn't go. And frankly, Drupal
developers should stop
2009/8/21 Jean-Michel Pouré j...@poure.com:
PostgreSQL requires all non-aggregated fields to be present in the GROUP
BY clause (I fixed 10 such issues in Drupal code).
http://drupal.org/node/30
Why can't PostgreSQL add the required field automatically? Could this be
added to PostgreSQL
* Greg Stark (gsst...@mit.edu) wrote:
select distinct on (a) a,b,c from a ORDER BY a,b,c
But Postgres insists you have an ORDER BY which has to agree with the
DISTINCT ON columns and provide some extra column(s) to determine
which values of b,c are chosen.
Not quite technically correct.
2009/8/22 Stephen Frost sfr...@snowman.net:
Hrmm. That sounds kinda neat, but you'd still have to specify one of
the columns in the GROUP BY, I presume? Or could you just say 'GROUP
BY' without any columns, and have it GROUP BY the key of the table
you're using?
You would have to specify
* Greg Stark (gsst...@mit.edu) wrote:
You would have to specify the key. I think typically you would have
something like:
SELECT a.*, sum(b.col)
FROM a,b
GROUP BY a.pk
Ahhh, ok, this makes more sense. This is SQL standard? Do we have a
TODO for it?
The database knows that it can
Stephen Frost sfr...@snowman.net writes:
Right. It strikes me as a relativly small amount of work to get the
initial just add the columns to the group by logic implemented.
Well, no, you *aren't* adding the columns to the GROUP BY. You're just
not throwing the error. You really don't want to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Right. It strikes me as a relativly small amount of work to get the
initial just add the columns to the group by logic implemented.
Well, no, you *aren't* adding the columns to the GROUP BY. You're just
not
2009/8/22 Stephen Frost sfr...@snowman.net:
* Greg Stark (gsst...@mit.edu) wrote:
You would have to specify the key. I think typically you would have
something like:
SELECT a.*, sum(b.col)
FROM a,b
GROUP BY a.pk
Ahhh, ok, this makes more sense. This is SQL standard?
Incidentally it
* Greg Stark (gsst...@mit.edu) wrote:
So not many uses of it in MySQL actually *would* be valid if we
implemented the shortcut. But MySQL doesn't enforce that so it serves
that purpose as well as what we get out of DISTINCT ON.
That's probably a good thing- if they're valid then we'd probably
2009/8/22 Stephen Frost sfr...@snowman.net:
This is a bit trickier than it looks because it makes the validity of a
query dependent on the existence of an appropriate uniqueness
constraint; thus for example DROP CONSTRAINT might invalidate a stored
rule or view. See prior discussions.
Ah,
Greg Stark gsst...@mit.edu writes:
The first step is probably to do the opposite of what we're talking
about here: cases where people *have* added extra columns to the GROUP
BY key so they can use those columns in their select list. We can
remove those columns from the sort or hash comparison
On Friday 21 August 2009 04:01:36 pm Andrew Dunstan wrote:
Jean-Michel Pouré wrote:
BTW, why don't we have a multi-argument version of CONCAT()? In 8.4,
it
would be possible ... I should add it to mysqlcompat library.
yes. In PostgreSQL core ...
No. That is exactly where it
Greg Stark wrote:
If Postgres changed on this front it would be to support the SQL
Standard concept of functional dependency. In cases where some
columns are guaranteed to be unique you can leave them out of the
GROUP BY but still use them in the select list. This isn't MySQL's
behaviour of
Andrew Dunstan and...@dunslane.net writes:
Jean-Michel Pouré wrote:
Why can't PostgreSQL add the required field automatically? Could this be
added to PostgreSQL to-do-list?
Isn't that contrary to the standard?
As of SQL99 it's supposed to be legal if you're grouping by a primary key
(or some
30 matches
Mail list logo