[development] Do not let postgresql hold back great patches
kb at 2bits.com
Tue Dec 4 01:19:54 UTC 2007
Yes, but it is one level above native date/time fields.
All databases have equivalent functions for date math and the like (EXTRACT,
My point was the need for in-SQL operations for queries, which no matter how
you abstract the individual CRUD (we already have user_load() and
node_load() for that), you still need in-SQL for reporting and aggreggation.
On Dec 3, 2007 7:40 PM, Larry Garfield <larry at garfieldtech.com> wrote:
> On Mon, 3 Dec 2007 18:42:56 -0500, "Khalid Baheyeldin" <kb at 2bits.com>
> > On Dec 3, 2007 1:49 AM, Larry Garfield <larry at garfieldtech.com> wrote:
> >> As for in-SQL operations on the date value, like MONTH() or YEAR() in
> >> MySQL?
> >> If someone has an idea for those that doesn't involve regexing every
> > query
> >> I
> >> would dearly love to hear it. :-)
> > The current use of UNIX timestamp is a compromise, and has its issues,
> > still allows in-SQL operations.
> > In-SQL operations is very very important. Going to ActiveRecord type of
> > abstraction without the ability to do aggregate operations on the data
> > just not an option.
> > Without in-SQL, doing things like:
> > select n.nid, n.type, n.title, count(*) as num_votes, avg(value) as
> > avg_vote
> > from votingapi_vote v inner join node n on content_id = n.nid where
> > =
> > 'image' and n.created between unix_timestamp('2007-11-01 00:00:00') and
> > unix_timestamp('2007-11-30 23:59:59') group by v.content_id having
> > num_votes
> >> 1 order by avg_vote desc, num_votes desc limit 20;
> > Would be impossible, or would entail very expensive full table scans.
> Except that unix_timestamp() is MySQL-specific, isn't it?
> --Larry Garfield
Khalid M. Baheyeldin
Drupal optimization, development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development