Re: [GENERAL] Incrementing a Serial Field

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: daveh(at)insightdist(dot)com (David Hartwig)
Cc: bkruger(at)mindspring(dot)com, pgsql-general(at)postgreSQL(dot)org, byronn(at)insightdist(dot)com
Subject: Re: [GENERAL] Incrementing a Serial Field
Date: 1998-11-09 20:57:09
Message-ID: 199811092057.PAA04188@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
>
> Bob Kruger wrote:
>
> > The second question is that I noticed the ODBC bug (feature?) when linking
> > Postgres to MS Access still exists. This bug occurs when linking a MS
> > Access table to a Postgres table, and identifying more than one field as
> > the unique record identifier. This makes Postgres run until it exhausts
> > all available memory. Does anyone know a way around this? Enabling read
> > only ODBC is a feature I would like to make available, but I do not want
> > the possibility of postgres crashing because of an error on the part of a
> > MS Access user.
> >
> > BTW - Having capability to be linked to an Access database is not an
> > option. The current project I am working on calls for that, so it is a
> > necessary evil that I hav to live with.
> >
>
> In the driver connection settings add the following line.
>
> SET ksql TO 'on';
>
> Stands for: keyset query optimization. This is not considered a final
> solution. As such, it is undocumented. Some time in the next day or so, we
> will be releasing a version of the driver which will automatically SET ksqo.
>
> You will most likely be satisfied with the results. One problem with this
> solution, however, is that it does not work if you have any (some kinds of?)
> arrays in the table you are browsing. This is a sideffect of the rewrite to a
> UNION which performs an internal sort unique.
>
> Also, if you are using row versioning you may need to overload some operators
> for xid and int4. I have included a script that will take care of this.
>
> Bruce, can I get these operators hardcoded into 6.4.1- assuming there will be
> one. The operators necessitated by the UNION sideffects.
>

Ths killer is that 6.4.1, if we have one, will not require a
dump/reload, because it is a minor release. We can add the stuff, but
people who do not initdb as part of 6.4.1 will not see the changes.

> -- Insight Distribution Systems - System V - Apr 1998
> -- @(#)xidint4.sql 1.2 :/sccs/sql/extend/s.xidint4.sql 10/2/98 13:40:19"
>
> create function int4eq(xid,int4)
> returns bool
> as ''
> language 'internal';
>
> create operator = (
> leftarg=xid,
> rightarg=int4,
> procedure=int4eq,
> commutator='=',
> negator='<>',
> restrict=eqsel,
> join=eqjoinsel
> );
>
> create function int4lt(xid,xid)
> returns bool
> as ''
> language 'internal';
>
> create operator < (
> leftarg=xid,
> rightarg=xid,
> procedure=int4lt,
> commutator='=',
> negator='<>',
> restrict=eqsel,
> join=eqjoinsel
> );
>
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gene Selkov Jr. 1998-11-10 04:18:14 Re: [GENERAL] Case insensitive "contains" search
Previous Message Robert Church 1998-11-09 20:05:29 'now' is the future