Rodrigo Carvalhaes wrote:
Hi Guys!
I need to make an UPDATE on a column reordering it with a sequence
using order by a description.
Confusing??? Well.. Let me give an example...
Today, my table it's organized like this:
Code / Description
9 Orange
15 Apple
1
Dan Langille wrote:
The goal of my query is: given a book, what did other people who
bought this book also buy? I plan the list the 5 most popular such
books. In reality, this isn't about books, but that makes it easier
to understand I think.
We have a table of customer_id
On 26 Apr 2005 at 14:24, Christoph Haller wrote:
Dan Langille wrote:
The goal of my query is: given a book, what did other people who
bought this book also buy? I plan the list the 5 most popular such
books. In reality, this isn't about books, but that makes it easier
to understand
O Christoph Haller Apr 26, 2005 :
Dan Langille wrote:
The goal of my query is: given a book, what did other people who
bought this book also buy? I plan the list the 5 most popular such
books. In reality, this isn't about books, but that makes it easier
to understand I think.
Dan Langille wrote:
On 26 Apr 2005 at 14:24, Christoph Haller wrote:
Dan Langille wrote:
The goal of my query is: given a book, what did other people who
bought this book also buy? I plan the list the 5 most popular such
books. In reality, this isn't about books, but that
Thanksyou and Franz for your help. Simple and efficient... I was
blind The plpgsql "for" is the perfect solution
It was great. Have a nice week!!!
Cheers,
Rodrigo Carvalhaes
Christoph Haller wrote:
Rodrigo Carvalhaes wrote:
Hi Guys!
I need to make an UPDATE on a column
According to the manual at:
http://www.postgresql.org/docs/7.4/static/functions-geometry.html
The PostgreSQL query planner will consider using an R-tree index whenever an
indexed column is
involved in a comparison using one of these operators: , , , , @, ~=,
(Refer to Section
9.9 about the
On 2005-04-26, TJ O'Donnell [EMAIL PROTECTED] wrote:
But I think I might be able to do better (faster) using R-trees.
Bitstrings can be thought of as containing when one bitstring has all the
same bits set as another, even if it has other bits set too - this is the
gist of the first
TJ O'Donnell [EMAIL PROTECTED] writes:
Shouldn't the ~ (contains) operator be included also?
Isn't ~ the commutator of @ ?
Yeah, it looks like the documentation is in error:
regression=# select amopopr::regoperator,amopstrategy from pg_amop where
amopclaid in
regression-# (select oid from
