Re: CREATE USER and ODBC

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: Jarmo Paavilainen <netletter(at)comder(dot)com>
Cc: pgsql-general(at)hub(dot)org
Subject: Re: CREATE USER and ODBC
Date: 2000-09-16 11:03:04
Message-ID: 200009161103.GAA05134@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Enrico Comini 2000-09-16 11:18:32
Previous Message Jarmo Paavilainen 2000-09-16 08:32:30 CREATE USER and ODBC