Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tino Wildenhain <tino(at)wildenhain(dot)de>, pgsql-general(at)postgresql(dot)org
Subject: Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does
Date: 2002-08-14 18:09:20
Message-ID: 200208141809.g7EI9Kn14633@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)wildenhain(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joe Conway 2002-08-14 18:09:41 Re: [HACKERS] [GENERAL] workaround for lack of REPLACE() function
Previous Message Christian Mock 2002-08-14 17:53:19 Re: performance with triggers depends on table size?