Обсуждение: RE: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs
I haven't looked at DATETIME stuff, but does Postgres not have something similar to Oracle's SYSDATE? In Oracle you can set an Oracle DATE column to have a default of SYSDATE. This way Oracle can fill in the column at the time an insert is done. - Greg > -----Original Message----- > From: Byron Nikolaidis [SMTP:byronn@insightdist.com] > Sent: Wednesday, June 10, 1998 10:46 AM > To: Jose' Soares Da Silva; interfaces postgres > Subject: Re: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs > > > > > Byron Nikolaidis wrote: > > > Jose' Soares Da Silva wrote: > > > > > My problem is that I need a TIMESTAMP data type defined in M$-Access > because > > > M$-Access wants it to have best performance when it updates a table > via ODBC. > > > M$-Access doesn't lock a record being modified, to allow control > concurrent > > > access to data M$-Access reads again the record to verify if it was > modified by > > > another user, before update it to database. > > > If there's a TIMESTAMP M$-Access verifies only, if this field was > modified, > > > otherwise it verifies every field of the table, and obviously it is > slower. > > > I beleave it would very useful if you could add this feature to > psqlodbc. > > > Thanks, Jose' > > > > > > > I did some testing with SQLSpecialColumns 'SQL_ROWVER'. As I noted in my > previous mail, > we dont return anything for this function in the driver. I tried > hard-coding a column > that was a SQL_TIMESTAMP type (in my table it was a postgres 'datetime'). > Access did use > that column. Here are the results: > > test1 table > ---------- > a,c,d,e,f,g = int2 > b,h = varchar > datetim = datetime > > Access results without ROWVER (this is the way things currently are) > --------------------------------------------------------------------- > BEGIN > update test1 set b='hello' where a=7 AND b='other' AND c=3 AND d=4 AND e > is NULL AND f is > NULL AND g=5 AND h='stuff' > COMMIT > > Access results with ROWVER > ------------------------------- > BEGIN > update test1 set b='hello' where a=7 AND datetim = '1998-05-30 10:59:00'; > select a,b,c,d,e,f,g,h,datetim where a=7; > COMMIT > > Conclusion: > ----------- > The update statement was definately smaller and only involved the key and > the timestamp > column. The extra select that it does to verify no one has changed > anything (using the > value of the timestamp) slowed the update down, though. I don't think the > speed gain on > the smaller update statement makes up for the extra query. In either > case, the backend > locking problem would still prevent the update if the table was opened by > someone else (or > even the same application, as in our declare/fetch problem). > > Also, something would have to be done to actually put a timestamp value in > every time a > row was added or updated. Access actually prevented me from entering a > value in my > 'datetim' field because it assumed the dbms would fill it in. I guess > you could use a > trigger to update the timestamp field. OR if we had a pseudo column that > qualified, we > could use that, however when I tried using a pseudo column, Access barfed > on me > complaining "Table TMP%#$$^ already exists". If I added the pseudo > column to the output, > the message went away. I have no idea what the heck that means? > > Any ideas or thoughts? > > Byron > > >
Krasnow, Greg wrote: > I haven't looked at DATETIME stuff, but does Postgres not have something > similar to Oracle's SYSDATE? In Oracle you can set an Oracle DATE column to > have a default of SYSDATE. This way Oracle can fill in the column at the > time an insert is done. > Yes, you are right, and I noticed Jose' earlier mail about this on the 'sql' list. If you do: create table x (a timestamp DEFAULT CURRENT_TIMESTAMP, b varchar); It works AND it puts in the current time at INSERT of the new row. (I noticed if you use CURRENT_TIME instead, you get the time you created the table at, for every row, which is not very useful.) The only problem is that it doesn't change the value on an UPDATE! Any thoughts? Byron
Byron Nikolaidis wrote: > > Krasnow, Greg wrote: > > > I haven't looked at DATETIME stuff, but does Postgres not have something > > similar to Oracle's SYSDATE? In Oracle you can set an Oracle DATE column to > > have a default of SYSDATE. This way Oracle can fill in the column at the > > time an insert is done. > > > > Yes, you are right, and I noticed Jose' earlier mail about this on the 'sql' > list. > > If you do: > > create table x (a timestamp DEFAULT CURRENT_TIMESTAMP, b varchar); > > It works AND it puts in the current time at INSERT of the new row. (I noticed > if you use CURRENT_TIME instead, you get the time you created the table at, for > every row, which is not very useful.) > > The only problem is that it doesn't change the value on an UPDATE! > > Any thoughts? Why not use the system column tmin for this purpose? hannu=> create table test(i int); CREATE hannu=> insert into test values(5); INSERT 17454 1 hannu=> select tmin,tmax,i from test; tmin |tmax |i -----------------------------+-------+- Thu Jun 11 11:12:17 1998 EEST|current|5 (1 row) hannu=> update test set i=2; UPDATE 1 hannu=> select tmin,tmax,i from test; tmin |tmax |i -----------------------------+-------+- Thu Jun 11 11:13:00 1998 EEST|current|2 (1 row) ------ Hannu
On Wed, 10 Jun 1998, Byron Nikolaidis wrote:
>
>
> Krasnow, Greg wrote:
>
> > I haven't looked at DATETIME stuff, but does Postgres not have something
> > similar to Oracle's SYSDATE? In Oracle you can set an Oracle DATE column to
> > have a default of SYSDATE. This way Oracle can fill in the column at the
> > time an insert is done.
> >
>
> Yes, you are right, and I noticed Jose' earlier mail about this on the 'sql'
> list.
>
> If you do:
>
> create table x (a timestamp DEFAULT CURRENT_TIMESTAMP, b varchar);
>
> It works AND it puts in the current time at INSERT of the new row. (I noticed
> if you use CURRENT_TIME instead, you get the time you created the table at, for
> every row, which is not very useful.)
>
> The only problem is that it doesn't change the value on an UPDATE!
>
> Any thoughts?
>
> Byron
>
Well, I think that it may be solved by creating a trigger, I've done this
and seem it works.
---------------------------------------------------------------------------
CREATE TABLE version_test (
username CHAR(10),
version TIMESTAMP
);
CREATE TRIGGER version
BEFORE INSERT OR UPDATE ON version_test
FOR EACH ROW
EXECUTE PROCEDURE version(version);
---------------------------------------------------------------------------
/*
* version.c
* $Modified: 9/6/98 by Jose' Soares Da Silva - inserito un campo timestamp.
*
* insert a value into a timestamp column in response to a trigger
* usage: version(data_time)
*/
#include "executor/spi.h" /* this is what you need to work with SPI */
#include "commands/trigger.h" /* -"- and triggers */
HeapTuple version(void);
HeapTuple version()
{
Trigger *trigger; /* to get trigger name */
Datum newval; /* new value of column */
char **args; /* arguments */
char *relname; /* triggered relation name */
Relation rel; /* triggered relation */
HeapTuple rettuple = NULL;
TupleDesc tupdesc; /* tuple description */
int attnum;
if (!CurrentTriggerData)
elog(ERROR, "version: i triggers non sono inizializati");
if (TRIGGER_FIRED_FOR_STATEMENT(CurrentTriggerData->tg_event))
elog(ERROR, "version: impossibile usare l'evento STATEMENT");
if (TRIGGER_FIRED_AFTER(CurrentTriggerData->tg_event))
elog(ERROR, "version: deve essere creata prima dell'evento");
if (TRIGGER_FIRED_BY_INSERT(CurrentTriggerData->tg_event))
rettuple = CurrentTriggerData->tg_trigtuple;
else if (TRIGGER_FIRED_BY_UPDATE(CurrentTriggerData->tg_event))
rettuple = CurrentTriggerData->tg_newtuple;
else
elog(ERROR, "version: impossibile usare l'evento DELETE");
rel = CurrentTriggerData->tg_relation;
relname = SPI_getrelname(rel);
trigger = CurrentTriggerData->tg_trigger;
args = trigger->tgargs;
tupdesc = rel->rd_att;
CurrentTriggerData = NULL;
/* update the TIMESTAMP */
attnum = SPI_fnumber(tupdesc,args[1]);
newval = PointerGetDatum(now());
rettuple = SPI_modifytuple(rel, rettuple, 1, &attnum, &newval, NULL);
if (rettuple == NULL)
elog(ERROR, "version (%s): %d ritornato da SPI_modifytuple",
relname, SPI_result);
pfree(relname);
return (rettuple);
---------------------------------------------------------------------------
Ciao, Jose'
On Thu, 11 Jun 1998, Hannu wrote:
> Byron Nikolaidis wrote:
> >
> > Krasnow, Greg wrote:
> >
> > > I haven't looked at DATETIME stuff, but does Postgres not have something
> > > similar to Oracle's SYSDATE? In Oracle you can set an Oracle DATE column to
> > > have a default of SYSDATE. This way Oracle can fill in the column at the
> > > time an insert is done.
> > >
> >
> > Yes, you are right, and I noticed Jose' earlier mail about this on the 'sql'
> > list.
> >
> > If you do:
> >
> > create table x (a timestamp DEFAULT CURRENT_TIMESTAMP, b varchar);
> >
> > It works AND it puts in the current time at INSERT of the new row. (I noticed
> > if you use CURRENT_TIME instead, you get the time you created the table at, for
> > every row, which is not very useful.)
> >
> > The only problem is that it doesn't change the value on an UPDATE!
> >
> > Any thoughts?
>
> Why not use the system column tmin for this purpose?
>
> hannu=> create table test(i int);
> CREATE
> hannu=> insert into test values(5);
> INSERT 17454 1
> hannu=> select tmin,tmax,i from test;
> tmin |tmax |i
> -----------------------------+-------+-
> Thu Jun 11 11:12:17 1998 EEST|current|5
> (1 row)
>
> hannu=> update test set i=2;
> UPDATE 1
> hannu=> select tmin,tmax,i from test;
> tmin |tmax |i
> -----------------------------+-------+-
> Thu Jun 11 11:13:00 1998 EEST|current|2
> (1 row)
>
> ------
> Hannu
>
One minute! what's that tmin?
What version do you have?
I have v6.3.2 and it doesn't know tmin.
prova=> create table test(i int);
CREATE
prova=> insert into test values(5);
INSERT 15650 1
prova=> select tmin,tmax,i from test;
ERROR: attribute 'tmin' not found
Jose'
Hi,
After some testing with the ROWVER stuff, I have come up with the
following and wanted to see what people thought about it:
What I have now is if you have a timestamp type column and its field
name is "timestamp", the driver will report it as a ROWVER column in
SQLSpecialColumns. This causes Access to use it as a versioning
column. Does this seem too restrictive? Do you have other ideas of
what should constitute a versioning column? I think the field name
should be agreed upon and fixed in the driver, don't you? The other
caveat about this method is that you would have to supply a trigger to
update this 'timestamp' field on INSERT and UPDATE.
One of the things I can't get around in Access is using a column in
SQLSpecialColumns that does not appear in SQLColumns (i.e., a
pseudo-column). For example, even if we had a 'tmin' column (I know it
was removed for 6.3.2), or wanted to try using the 'xmin' column, we
couldn't use it as a pseudo column. We would have to display the
column. Access spits out an ugly message when I try to use a
pseudo-column ("Table TMP%#MAU@ already exists").
I have tested other types besides timestamps, like int4, and they seem
to work fine as a versioning column. So, we could use the postgres
'xmin' column, if we displayed it in SQLColumns. It seems to always
update so you wouldn't have to worry about a trigger. I'm not sure what
end-users would think about seeing these ugly columns in Access? Any
thoughts about that?
Please give me some feedback on this.
Byron
Jose', I got row versioning working with the "xmin" field. Since it is a system column, and automatically updates, you would not need triggers all over the place on every table. I made it a datasource option called "Row Versioning". It works well with Access except for two minor caveats: 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around that I can see. Access, thus displays it. Users can of course hide the column if they hate looking at it. And Access won't let you type into this field which is good. 2) You have to create an '=' operator for the xid type on the postgres side since one does not already exist. I have the code to do it if you are interested (it is very small). For 6.4, we would make sure this operator is added. Byron
Byron Nikolaidis wrote: > > Hi, ... > > I have tested other types besides timestamps, like int4, and they seem > to work fine as a versioning column. So, we could use the postgres > 'xmin' column, if we displayed it in SQLColumns. It seems to always > update so you wouldn't have to worry about a trigger. I'm not sure what > end-users would think about seeing these ugly columns in Access? Any > thoughts about that? Is'nt there some way in ODBC to return some kind of _system_ columns, like there are system tables ? I think that PostgreSQL is not the only database that has system columns Hannu
On Thu, 11 Jun 1998, Byron Nikolaidis wrote:
> Jose',
>
> I got row versioning working with the "xmin" field. Since it is a system column, and
> automatically updates, you would not need triggers all over the place on every table.
> I made it a datasource option called "Row Versioning".
>
> It works well with Access except for two minor caveats:
>
> 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around
> that I can see. Access, thus displays it. Users can of course hide the column if they
> hate looking at it. And Access won't let you type into this field which is good.
>
> 2) You have to create an '=' operator for the xid type on the postgres side since one
> does not already exist. I have the code to do it if you are interested (it is very
> small). For 6.4, we would make sure this operator is added.
>
Ok Byron, I think this is a good solution.
In this way we don't need to add a TIMESTAMP to every table there's already a
XMIN present.
In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
DATETIME or we can't because Access beleaves that's a ROWVER ?
I would like to try it. Please Byron may you send me the code for '=' operator
for xid type.
Jose'
Hannu wrote: > Is'nt there some way in ODBC to return some kind of _system_ columns, > like there are system tables ? > > I think that PostgreSQL is not the only database that has system columns > Yes, the 'pseudo' column attribute in SQLSpecialColumns does this. I am setting it for the xmin field, but Access never even bothers to look at it (it never binds the column or does GetData). It is only interested in the column name!?! You would think that you could report system columns like 'xmin' just in SQLSpecialColumns and not have to also specify them in SQLColumns. But as I said, if I don't also specify the column in SQLColumns, Access barfs with the message "Table TMP%#MAU@ already exists." when I try to open the table. The linking phase works fine though. It doesn't make much sense. If you have any ideas what the heck that message means, PLEASE TELL ME!!!! Byron
Here is is what you will need. I hope you know how to compile a shared lib for your
platform. This can be an adventure if you have not done it before. You will have to
adjust the path in the CREATE FUNCTION statement to your lib dir. Run the SQL after you
compile and install the shared lib. To test, do something like:
SELECT * FROM foo WHERE xmin = {some_constant}
I plan to submit a patch to make this a part of the 6.4 base release.
Jose' Soares Da Silva wrote:
> On Thu, 11 Jun 1998, Byron Nikolaidis wrote:
>
> > Jose',
> >
> > I got row versioning working with the "xmin" field. Since it is a system column, and
> > automatically updates, you would not need triggers all over the place on every table.
> > I made it a datasource option called "Row Versioning".
> >
> > It works well with Access except for two minor caveats:
> >
> > 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around
> > that I can see. Access, thus displays it. Users can of course hide the column if they
> > hate looking at it. And Access won't let you type into this field which is good.
> >
> > 2) You have to create an '=' operator for the xid type on the postgres side since one
> > does not already exist. I have the code to do it if you are interested (it is very
> > small). For 6.4, we would make sure this operator is added.
> >
> Ok Byron, I think this is a good solution.
> In this way we don't need to add a TIMESTAMP to every table there's already a
> XMIN present.
> In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
> DATETIME or we can't because Access beleaves that's a ROWVER ?
> I would like to try it. Please Byron may you send me the code for '=' operator
> for xid type.
> Jose'
/* Insight Distribution Systems - System V - Apr 1998 */
static char accntnum_c[] = "@(#)accntnum.c 1.1 /sccs/sql/extend/s.accntnum.c 4/28/98 09:06:54";
#include <stdio.h> /* for sprintf() */
#include <string.h>
#include "postgres.h"
#include "utils/palloc.h"
bool
xidint4_eq(int32 arg1, int32 arg2)
{
return (arg1 == arg2);
}
-- Insight Distribution Systems - System V - Apr 1998
-- %W% :%P% %G% %U%"
create function xidint4_eq(xid,int4)
returns bool
as '/ceo/pgsql/lib/xidint4.so'
language 'c';
create operator = (
leftarg=xid,
rightarg=int4,
procedure=xidint4_eq,
commutator='=',
negator='<>',
restrict=eqsel,
join=eqjoinsel
);
Jose' Soares Da Silva wrote: > Ok Byron, I think this is a good solution. > In this way we don't need to add a TIMESTAMP to every table there's already a > XMIN present. > In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as > DATETIME or we can't because Access beleaves that's a ROWVER ? > I would like to try it. Please Byron may you send me the code for '=' operator > for xid type. > Jose' I added the postgres timestamp type and mapped it to SQL_TIMESTAMP, so Access recognizes it now as a Date/Time. It does not automatically recognize it is a ROWVER. Did you read somewhere that it did that? In my testing it never did, UNLESS, I mentioned the column in SQLSpecialColumns and specifically said it was a ROWVER. Byron P.S., Dave Hartwig is sending you the code for the xid '=' operator.
Oops! Here's a better way without the shared module.
-- Overload int4eq
create function int4eq(xid,int4)
returns bool
as ''
language 'internal';
create operator = (
leftarg=xid,
rightarg=int4,
procedure=int4eq,
commutator='=',
negator='<>',
restrict=eqsel,
join=eqjoinsel
);
David Hartwig wrote:
> Here is is what you will need. I hope you know how to compile a shared lib for your
> platform. This can be an adventure if you have not done it before. You will have to
> adjust the path in the CREATE FUNCTION statement to your lib dir. Run the SQL after you
> compile and install the shared lib. To test, do something like:
>
> SELECT * FROM foo WHERE xmin = {some_constant}
>
> I plan to submit a patch to make this a part of the 6.4 base release.
>
> Jose' Soares Da Silva wrote:
>
> > On Thu, 11 Jun 1998, Byron Nikolaidis wrote:
> >
> > > Jose',
> > >
> > > I got row versioning working with the "xmin" field. Since it is a system column, and
> > > automatically updates, you would not need triggers all over the place on every table.
> > > I made it a datasource option called "Row Versioning".
> > >
> > > It works well with Access except for two minor caveats:
> > >
> > > 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around
> > > that I can see. Access, thus displays it. Users can of course hide the column if they
> > > hate looking at it. And Access won't let you type into this field which is good.
> > >
> > > 2) You have to create an '=' operator for the xid type on the postgres side since one
> > > does not already exist. I have the code to do it if you are interested (it is very
> > > small). For 6.4, we would make sure this operator is added.
> > >
> > Ok Byron, I think this is a good solution.
> > In this way we don't need to add a TIMESTAMP to every table there's already a
> > XMIN present.
> > In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
> > DATETIME or we can't because Access beleaves that's a ROWVER ?
> > I would like to try it. Please Byron may you send me the code for '=' operator
> > for xid type.
> > Jose'
>
> ------------------------------------------------------------------------
> /* Insight Distribution Systems - System V - Apr 1998 */
> static char accntnum_c[] = "@(#)accntnum.c 1.1 /sccs/sql/extend/s.accntnum.c 4/28/98 09:06:54";
>
> #include <stdio.h> /* for sprintf() */
> #include <string.h>
> #include "postgres.h"
> #include "utils/palloc.h"
>
> bool
> xidint4_eq(int32 arg1, int32 arg2)
> {
> return (arg1 == arg2);
> }
>
> ------------------------------------------------------------------------
> -- Insight Distribution Systems - System V - Apr 1998
> -- %W% :%P% %G% %U%"
>
> create function xidint4_eq(xid,int4)
> returns bool
> as '/ceo/pgsql/lib/xidint4.so'
> language 'c';
>
> create operator = (
> leftarg=xid,
> rightarg=int4,
> procedure=xidint4_eq,
> commutator='=',
> negator='<>',
> restrict=eqsel,
> join=eqjoinsel
> );
I compiled and I installed successful the xid operator, I tried it
using: SELECT * FROM foo WHERE xmin = {some_constant}
and it works.
I download psqlodbc.dll v06.03.0244, I tried it but seems that doesn't work yet.
Did I forget something ?
Thanks in any way for your work David.
I'm going for vaccations next week, so forgive me if I don't replay for a week.
Jose'
On Fri, 12 Jun 1998, David Hartwig wrote:
> > > 2) You have to create an '=' operator for the xid type on the postgres side since one
> Here is is what you will need. I hope you know how to compile a shared lib for your
> platform. This can be an adventure if you have not done it before. You will have to
> adjust the path in the CREATE FUNCTION statement to your lib dir. Run the SQL after you
> compile and install the shared lib. To test, do something like:
>
> SELECT * FROM foo WHERE xmin = {some_constant}
>
> I plan to submit a patch to make this a part of the 6.4 base release.
>
>
>
>
> Jose' Soares Da Silva wrote:
>
> > On Thu, 11 Jun 1998, Byron Nikolaidis wrote:
> >
> > > Jose',
> > >
> > > I got row versioning working with the "xmin" field. Since it is a system column, and
> > > automatically updates, you would not need triggers all over the place on every table.
> > > I made it a datasource option called "Row Versioning".
> > >
> > > It works well with Access except for two minor caveats:
> > >
> > > 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around
> > > that I can see. Access, thus displays it. Users can of course hide the column if they
> > > hate looking at it. And Access won't let you type into this field which is good.
> > >
> > > 2) You have to create an '=' operator for the xid type on the postgres side since one
> > > does not already exist. I have the code to do it if you are interested (it is very
> > > small). For 6.4, we would make sure this operator is added.
> > >
> > Ok Byron, I think this is a good solution.
> > In this way we don't need to add a TIMESTAMP to every table there's already a
> > XMIN present.
> > In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
> > DATETIME or we can't because Access beleaves that's a ROWVER ?
> > I would like to try it. Please Byron may you send me the code for '=' operator
> > for xid type.
> > Jose'
>
On Fri, 12 Jun 1998, Byron Nikolaidis wrote:
>
>
> Jose' Soares Da Silva wrote:
>
> > Ok Byron, I think this is a good solution.
> > In this way we don't need to add a TIMESTAMP to every table there's already a
> > XMIN present.
> > In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
> > DATETIME or we can't because Access beleaves that's a ROWVER ?
> > I would like to try it. Please Byron may you send me the code for '=' operator
> > for xid type.
> > Jose'
>
>
> I added the postgres timestamp type and mapped it to SQL_TIMESTAMP, so Access recognizes it
Good.
> now as a Date/Time. It does not automatically recognize it is a ROWVER. Did you read
> somewhere that it did that? In my testing it never did, UNLESS, I mentioned the column in
> SQLSpecialColumns and specifically said it was a ROWVER.
I beleave we don't need that Access recognize timestamp as a ROWVER, now that
we have an xmin that do this.
Thanks, Jose'
Jose' Soares Da Silva wrote: > I download psqlodbc.dll v06.03.0244, I tried it but seems that doesn't work yet. > Did I forget something ? I haven't finished the new version (.0245) of the driver yet. It might be today. Byron
Byron has not yet posted the version that makes use of the xmin attribute. We have to keep on
him. He can be a real slacker.
Jose' Soares Da Silva wrote:
> I compiled and I installed successful the xid operator, I tried it
> using: SELECT * FROM foo WHERE xmin = {some_constant}
> and it works.
> I download psqlodbc.dll v06.03.0244, I tried it but seems that doesn't work yet.
> Did I forget something ?
> Thanks in any way for your work David.
> I'm going for vaccations next week, so forgive me if I don't replay for a week.
> Jose'
>
> On Fri, 12 Jun 1998, David Hartwig wrote:
> > > > 2) You have to create an '=' operator for the xid type on the postgres side since one
> > Here is is what you will need. I hope you know how to compile a shared lib for your
> > platform. This can be an adventure if you have not done it before. You will have to
> > adjust the path in the CREATE FUNCTION statement to your lib dir. Run the SQL after you
> > compile and install the shared lib. To test, do something like:
> >
> > SELECT * FROM foo WHERE xmin = {some_constant}
> >
> > I plan to submit a patch to make this a part of the 6.4 base release.
> >
> >
> >
> >
> > Jose' Soares Da Silva wrote:
> >
> > > On Thu, 11 Jun 1998, Byron Nikolaidis wrote:
> > >
> > > > Jose',
> > > >
> > > > I got row versioning working with the "xmin" field. Since it is a system column, and
> > > > automatically updates, you would not need triggers all over the place on every table.
> > > > I made it a datasource option called "Row Versioning".
> > > >
> > > > It works well with Access except for two minor caveats:
> > > >
> > > > 1) The driver has to report the 'xmin' field in SQLColumns. There is no way around
> > > > that I can see. Access, thus displays it. Users can of course hide the column if they
> > > > hate looking at it. And Access won't let you type into this field which is good.
> > > >
> > > > 2) You have to create an '=' operator for the xid type on the postgres side since one
> > > > does not already exist. I have the code to do it if you are interested (it is very
> > > > small). For 6.4, we would make sure this operator is added.
> > > >
> > > Ok Byron, I think this is a good solution.
> > > In this way we don't need to add a TIMESTAMP to every table there's already a
> > > XMIN present.
> > > In any way, what's happen with TIMESTAMPs ? May we have Access recognize it as
> > > DATETIME or we can't because Access beleaves that's a ROWVER ?
> > > I would like to try it. Please Byron may you send me the code for '=' operator
> > > for xid type.
> > > Jose'
> >