Thread: CREATE USER and ODBC

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.

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.

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 #

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

I'm not subscribed to mySQL's lists either, so I won't venture a
comparison.  But reading a mailing list just naturally gives you
an inflated perception of the amount of trouble people run into.
After all, people who *aren't* having trouble have little reason
to post about it.

So I think it'd be a big mistake to draw any such conclusion based
on reading only one project's lists.

            regards, tom lane