Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does - Mailing list pgsql-general

From Bruce Momjian
Subject Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does
Date
Msg-id 200208141809.g7EI9Kn14633@candle.pha.pa.us
Whole thread Raw
In response to Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does not work  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin
List pgsql-general
I didn't realize ODBC would error out if a SET came that wasn't
recognized.  Can you confirm this?  We can add it to 7.3 backend as an
invisible option (not in postgresql.conf) and mention in the TODO it
should be removed in 7.4 or 7.5.

---------------------------------------------------------------------------

Tom Lane wrote:
> Tino Wildenhain <tino@wildenhain.de> writes:
> > Since I like to try some things out I would be happy with
> > a quick dirty patch, but neither the pgodbc source compiles
> > nor do I find the relevant parts to the option setting in
> > the postgres-sources so I could at least get it to a
> > "dummy-accept"
>
> Can't help you with pgodbc, but if you want "set ksqo" to be
> accepted, add a dummy variable in src/backend/utils/misc/guc.c
> (look at the entry for geqo for a model).
>
> > Btw, what happend to the ksqo anyways?
>
> It's been dead for several releases and showed no sign of ever getting
> fixed, so Bruce decided to take it out.
>
> Breaking older odbc drivers might be a sufficient reason to leave a
> dummy SET variable in there awhile longer, though.  Not sure.  The
> schema changes in 7.3 might mean that using an old driver would be a
> bad idea anyway.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-general by date:

Previous
From: Christian Mock
Date:
Subject: Re: performance with triggers depends on table size?
Next
From: Andrew Sullivan
Date:
Subject: Re: Transaction Exception Question