I read thru your info, thanks a lot. In fact, I only need to decide whether a table (the whole) has been updated since last query. I have some pulldown menus in a VB app which extract data from a remote site with slow connection. And the data in those tables for pulldowns changes rarely. So if the pulldown has to extract the data and transmit it thru slow connection, the pulldown will take a few seconds to be in action, which is a little bit annoying, especially if the data is the same as in the array of client. So if I can query the table, knowing that no data changed in the table since my last query, I can use the client side array as pulldown data without waiting for long transmition time.
I wonder if there is some more direct method, or thru the pg system tables to get this info. If there's not out there, I would use a trigger which will update a seperate table containing the last update time of all tables (not records) for pulldowns. -Jason ----- Original Message ----- From: "Richard Huxton" <[EMAIL PROTECTED]> To: "pg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 05, 2003 5:53 PM Subject: Re: [GENERAL] last update time of a table > On Friday 05 December 2003 01:21, pg wrote: > > Is there any simple way to query the most recent time of "changes" made to > > a table? > > > > I'm accessing my database with ODBC to a remote site thru internet. I want > > to eliminate some DUPLICATE long queries by evaluating whether the data has > > been > > changed since last query. What should I do? > > The canonical way is to add a last_changed column and a trigger to make sure > it gets updated whenever the rest of the row is. > > Go over to http://techdocs.postgresql.org/ and check in the plpgsql cookbook > or my Postgresql notes, or the archives come to think of it. > > -- > Richard Huxton > Archonet Ltd > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
