To fetch all updates since the last synchronization, the client would
calculated a value for $lastrevision by running this query on its local
database:
SELECT max(revision) AS lastrevision FROM codes;
It would then fetch all updated rows by running this query against the
server:
SELECT * FROM c
OOPs.
I mean
SELECT t1.id
, t1.fref
FROM t1
UNION ALL
SELECT t1.id
, t1.mref
FROM t1
- Original Message -
From:
Vincent
Hikida
To: Steven Verhoeven ; pgsql-general@postgresql.org ;
[EMAIL PROTECTED]
Sent: Sunday, March
SELECT t1.id
, t1.fref
FROM t1
UNION ALL
SELECT t2.id
, t2.mref
FROM t2
- Original Message -
From:
Steven Verhoeven
To: pgsql-general@postgresql.org ;
[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 4:36
AM
Subject: [GENERA
I actually just wanted to know if there is a way around this problem.
Obviously it is implemented that way for whatever reason.
I still though think some arguments given in some of the replies, while
probably correct, are besides the point.
Sorry. I was hoping someone else would answer.
I use a
The indexes are:
CREATE INDEX file_info_#_display_idx ON file_info_# (file_type,
file_parent_dir, file_name);
CREATE INDEX file_set_#_sync_idx ON file_set_# (fs_name, fs_parent_dir,
fs_type)
Are these not effective for the second query? If not, what should I
change or add? If so, would you
They are all 'not null' and I am trying to do exactly the kind of task
you described. I tried the first example on my DB and got a syntax error:
tle-bu=> SELECT a.file_name, a.file_parent_dir, a.file_type FROM
file_info_1 a WHERE NOT EXIST (SELECT NULL FROM file_set_1 b WHERE
b.fs_name=a.file
There are several ways. I am making the simplifying assumption that name,
type and dir cannot be NULL in either table. If they are the query is a
little more complicated.
The following are a couple of many techniques.
SELECT a.a_name
, a.a_type
, a.a_dir
FROM a_table
FROM t1 JOIN t2 ON t1.id = t2.id
)
- Original Message -
From: "Vincent Hikida" <[EMAIL PROTECTED]>
To: "peter pilsl" <[EMAIL PROTECTED]>; "PostgreSQL List"
<[EMAIL PROTECTED]>
Sent: Saturday, December 18, 2004 12:40 AM
S
One solution is
SELECT COALESCE(t1.id,t2.id)
, COALESCE(t1.name,t2.name)
FROM t1 FULL JOIN t2 ON t1.id = t2.id
- Original Message -
From: "peter pilsl" <[EMAIL PROTECTED]>
To: "PostgreSQL List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 15, 2004 1:03 PM
Subject: [GENERA
bution.
Vincent
- Original Message -
From: "Bruno Wolff III" <[EMAIL PROTECTED]>
To: "Vincent Hikida" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 02, 2004 12:10 PM
Subject: Re: [GENERAL] Indexes?
On Wed, Dec 01, 2004 at 23:16:48 -0800,
I believe that it is better to have a concatenated key of (toDate,FromDate).
The reason the toDate should come first is that for more "recent" records,
finding curDates less than toDate is much more selective than finding
curDates greater than fromDate. Actually I'm not sure if fromDate is that
I interpreted the question slightly differently. I understood it to mean the
most recent instance of red which doesn't make much sense in this case but
let's say the table was
color | date | entered_by
+-+---
red | 2004-01-19| John
I'm afraid, I'm not used to SQL92 join syntax and almost all my experience
is in Oracle but how about:
SELECT t1.uid
, t1.xname
, t2.uid
, t3.uid
FROM table1 t1
INNER JOIN table2 t2 ON t1.uid = t2.uid
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "elein" <[EMAIL PROTECTED]>
Cc: "Jan Wieck" <[EMAIL PROTECTED]>; "Vincent Hikida"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, July 24,
TABLE_NAME
FROM USER_TABLES
MINUS
SELECT TABLE_NAME
FROM [EMAIL PROTECTED]
/
And vice versa.
It then compared columns of common tables, the characteristics of the
columns, the indexes etc and used PL/SQL.
Vincent Hikida,
Member of Technical Staff - Urbana Software, Inc.
"A Personalized Lea
This is a great technique. It is especially useful in finance for
compounded interest for problems like the following
total return = ((1+janReturn)(1+febReturn)(1+marReturn))-1
I first learned it from an MBA in finance when I was looking over a
spreadsheet that she wrote.
Vincent Hikida
d body never even thought of this. Yes, I was actually
> stung by this particular while using it in Oracle.
>
> Vincent Hikida,
> Member of Technical Staff - Urbana Software, Inc.
> "A Personalized Learning Experience"
>
> www.UrbanaSoft.com
>
> - Original Me
17 matches
Mail list logo
