Re: [GENERAL] Incrementing a Serial Field - Mailing list pgsql-general

From Bruce Momjian
Subject Re: [GENERAL] Incrementing a Serial Field
Date
Msg-id 199811092057.PAA04188@candle.pha.pa.us
Whole thread Raw
In response to Re: [GENERAL] Incrementing a Serial Field  (David Hartwig <daveh@insightdist.com>)
List 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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: Robert Church
Date:
Subject: 'now' is the future
Next
From: "Gene Selkov Jr."
Date:
Subject: Re: [GENERAL] Case insensitive "contains" search