Re: CREATE USER and ODBC - Mailing list pgsql-general
From | Jan Wieck |
---|---|
Subject | Re: CREATE USER and ODBC |
Date | |
Msg-id | 200009161103.GAA05134@jupiter.jw.home Whole thread Raw |
In response to | CREATE USER and ODBC ("Jarmo Paavilainen" <netletter@comder.com>) |
Responses |
Re: CREATE USER and ODBC
|
List | pgsql-general |
Jarmo Paavilainen wrote: > Hi, > > Sorry if this has allready been sent, but Ive not received it from the list. > > I seem not to able to create a user through ODBC (through MFC classes). > > What I use is "CDatabase::ExecuteSQL( "CREATE USER jarmo WITH PASSWORD > 'myPass'" );" > > PostgreSQL complains that it can not create users inside a transaction (no > transaction is active, unless the ODBC driver creates one). And Ive logged > in as a superuser. I think the ODBC driver by default issues BEGIN TRANSACTION by itself. Dunno exactly, but there should be some "autocommit off" switch to it. > > PostgreSQL 7.0.2 (Linux) and ODBC driver 6.5 (Win98). > > // Jarmo > > PS. Ive followed this list for a while and... Is PostgreSQL more buggy and > harder to port to than mySQL, or is it just that Im not subscribed to mySQL > problem lists. DS. PostgreSQL has alot more features than MySQL like - Procedural languages - Triggers - Referential integrity - User defined functions, types, operators, aggregates - Views - Subselects just to name some of them. More functionality means more code, so it's not surprising that the absolute number of bug/problem reports might be bigger. But assuming from that that PostgreSQL is more buggy would IMHO not be accurate. Fact is, that more supported features usually make it easier to port an existing application. Look closer to the needs of the application (and/or future ones) before deciding which database to use. For example, if your application uses referential integrity (foreign key constraints) and/or triggers, it would require to move all that logic into each and every place where the application accesses the DB. For a WEB application with possibly hundreds of locations where tables are modified, this is calling for trouble! Just forget one single place and you run the risk of ending up with logically inconsistent data. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-general by date: