cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does not work

test

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Tino Wildenhain <tino@wildenhain.de> writes:

Now I'm unable to connect with either PGAdmin2 1.2
nor PGAdmin2 1.3.60 to the database - it returns an
unspecified error message.
I was able to track it down to the fact, that pgodbc
which in turn is used by pgadmin, sets some compatibility
parameters per default, such as "set ksqo to 'ON'"
which happens to gone away with postgresql-current.

My vague recollection is that this is fixed in the development version
of the ODBC driver, but someone from the ODBC camp should probably
confirm that...

Btw, what happend to the ksqo anyways?

KSQO hasn't actually worked since PostgreSQL 7.0, and was a bad idea
in the first place, IMHO. It has been put out of its misery in the
development sources.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

I'm looking for real world examples or case studies on
stretching PostgreSQL to the max as regards 24X7 OLTP
support for large databases with high numbers of
concurrent users. Anyone have a matrix comparing
features amongst the open source databases?

We host our application with 1000+/- MySQL "databases"
(AKA schemas) over the internet. There are lots of
enduser queries peaking at about 200 queries per
second for extended periods on some databases with a
rare max peak of 800 queries per second. Our
developers want to standardize on one open source
database for initial coding with 2ndary for Oracle and
SQLServer. Currently our primary database is
MySQL/MyISAM with lots of extra coding to work around
non-ANSI compliance, due mostly to the lack of
subselects and limited support (or non-production
support) for ACID compliant transactions.

We have looked at MySQL/Innodb but are concerned about
24X7 production support. We need to accommodate
database growth without having to bounce the database.
If we abandon MySQL we will have to migrate all the
data to the new database engine.

Any good PostgreSQL implementation stories you would
like to share? Any recommended web sites on PostgreSQL
case studies and white papers?

TIA!!!
D. B.

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

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

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

On Wed, Aug 14, 2002 at 09:21:43AM -0700, dbdweeb wrote:

Any good PostgreSQL implementation stories you would
like to share? Any recommended web sites on PostgreSQL
case studies and white papers?

There are no case studies of this yet, but the .info gTLD is built
using PostgreSQL. We have extremely stringent SLA demands, and we
can certainly take the load you're talking about. The Oracle
developers I used to work with thought that we were mighty fast, too.
In all, it's an all-around win.

A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110

Hi Tom, Bruce,

--On Mittwoch, 14. August 2002 14:09 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

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.

I can confirm this. Using odbc connection it trows the error as expected.
If I remove the setting [ ] disable ksqo in the odbc driver options,
everything works well. (This is unfortunately impossible for PgAccess,
since it does not use an ODBC DSN)

Perhaps its a better idea to update the odbc driver for 7.3.

For the moment I'll patch my postgres backend.

Funny thing I was already around guc.c but a first glance did not enlight
me well
enough ;)

Regards
Tino

Tino Wildenhain wrote:

Hi Tom, Bruce,

--On Mittwoch, 14. August 2002 14:09 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

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.

I can confirm this. Using odbc connection it trows the error as expected.
If I remove the setting [ ] disable ksqo in the odbc driver options,
everything works well. (This is unfortunately impossible for PgAccess,
since it does not use an ODBC DSN)

Perhaps its a better idea to update the odbc driver for 7.3.

Well, the 7.3 driver and the current driver at odbc.postgresql.org
should handle this correctly already and not enable ksqo.

-- 
  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