+ Reply to Thread
Results 1 to 4 of 4

Why PostgreSQL sucks.

  1. Why PostgreSQL sucks.

    I'm trying to get some code to run with PostgreSQL
    after succesfully getting it to run with MySQL and Sqlite,
    and if I had known Postgres was going to be such as pain
    in the butt, I would've refused. The current problem is
    that obvious call PQoidValue() doesn't work. The solution
    apparently is that currval(sequencename), which is just
    nifty except the INSERT statement doesn't say which field
    that is. Instead have I have to parse out the table name
    and then look up in my own schema definitions for which
    field that is. (Even though apparently I could get it in
    5 to 10 queries if there was a clearly documented explanation
    of how to SERIAL fields are scattered amongst those pg_%
    tables. The again I gave up trying to extract primary
    and unique constraints to recreate the simple functionality
    of SHOW CREATE TABLE.) And of course I have to construct
    a whole separate query just to get one piece of information
    that the library should've already known since it's one of
    the most obvious questions to be asked after an INSERT.

    ****.

    So why does PostgreSQL suck? It's not that some people
    decided they could make a better wheel than anyone else.
    Maybe they could. But if I can't fit that wheel on the
    existing waggon, it's useless pile of crap. It has got to
    be obvious by this time that going from something like
    Sqlite to PostgreSQL is going to be a bloody pain in the
    butt because Postgres is so pure and blessed and above
    the other databases that they cannot be botherred to provide
    an interface that allows a programmer to use standard
    query language and adapt an existing library interface
    that behaves in a similar fashion for every database.

    I have learned too late that what I really need to do is
    define a standard query language so that I can write the
    bulk of my code independent of the databases. Then write
    a per-database translator from the standard query language
    to the specific SQL of each database. And yes I know what
    the S of SQL stands for, it's a lie and very poor joke.

    One thing I've already learned is not depend on pg_%
    tables to discover the schema, but to retain the schema
    definition I used to create the database and parse that.
    Having all that stuff in a database is absolutely worthless
    if you can't be botherred to document what the tables
    really mean. I learned that lesson when I learned I have
    to parse REPLACE statements to extract the table to
    get the primary keys to translate the REPLACE into
    a DELETE followed by an INSERT. Thanks for all the lovely
    lectures on what Postgres thinks is proper query design
    so that they don't have to implement a simple assignment
    of x := v.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    God's a skeeball fanatic.

  2. Re: Why PostgreSQL sucks.

    SM Ryan schrieb:
    > I'm trying to get some code to run with PostgreSQL
    > after succesfully getting it to run with MySQL and Sqlite,


    You are comparing postgresql with mysql and sqlite. *ROFL*
    If you need postgres, then SQLIte and probably MySQL aren't any choice.
    So if SQLIte or MySQL ist suffiecient to you, then there is no need for
    postgres on the other hand, everything you can do with mysql can be
    easily done with postgres. If your design sucks then this is your problem.

    > and if I had known Postgres was going to be such as pain
    > in the butt, I would've refused. The current problem is
    > that obvious call PQoidValue() doesn't work. The solution
    > apparently is that currval(sequencename), which is just
    > nifty except the INSERT statement doesn't say which field
    > that is. Instead have I have to parse out the table name
    > and then look up in my own schema definitions for which
    > field that is. (Even though apparently I could get it in
    > 5 to 10 queries if there was a clearly documented explanation
    > of how to SERIAL fields are scattered amongst those pg_%
    > tables. The again I gave up trying to extract primary
    > and unique constraints to recreate the simple functionality
    > of SHOW CREATE TABLE.) And of course I have to construct
    > a whole separate query just to get one piece of information
    > that the library should've already known since it's one of
    > the most obvious questions to be asked after an INSERT.
    >
    > ****.


    This is clearly your fault, if you try to solve your problem in the
    stupiest way withpout using postgres functionality properly, then noone
    can help you
    >
    > So why does PostgreSQL suck? It's not that some people
    > decided they could make a better wheel than anyone else.
    > Maybe they could. But if I can't fit that wheel on the
    > existing waggon, it's useless pile of crap. It has got to


    If you try to fit a good wheel on a broken wagon and then complain that
    the vehicle won't run, you cannot blame the wheel.

    > be obvious by this time that going from something like
    > Sqlite to PostgreSQL is going to be a bloody pain in the
    > butt because Postgres is so pure and blessed and above
    > the other databases that they cannot be botherred to provide
    > an interface that allows a programmer to use standard
    > query language and adapt an existing library interface
    > that behaves in a similar fashion for every database.
    >
    > I have learned too late that what I really need to do is
    > define a standard query language so that I can write the
    > bulk of my code independent of the databases. Then write
    > a per-database translator from the standard query language
    > to the specific SQL of each database. And yes I know what
    > the S of SQL stands for, it's a lie and very poor joke.
    >
    > One thing I've already learned is not depend on pg_%
    > tables to discover the schema, but to retain the schema
    > definition I used to create the database and parse that.


    You don't seem like you have learnt a lot, you have no manners
    and you rude, remember the "F###"?
    No further discussion is needed on this. You are obviously not looking
    for help with your design, but instead causing trouble letting your
    anger about your own incapability spread to this list.

    --Ralf

  3. Re: Why PostgreSQL sucks.

    SM Ryan wrote:

    Yeah, Hello Mr. Ryan ...

    > I'm trying to get some code to run with PostgreSQL
    > after succesfully getting it to run with MySQL and Sqlite,
    > and if I had known Postgres was going to be such as pain
    > in the butt, I would've refused.


    You should read the documentation ...


    > The current problem is that obvious call PQoidValue()
    > doesn't work.


    Of course it won't work. Newer PostgreSQL versions don't
    create tables with OIDs, if you don't tell PG to use them.
    By the way, we are missing your explanation, what exactly
    does not work, the code you have written and what error
    code is returned ect. But 'InvalidOid' is in the docu ...
    you just have to read it.


    > The solution apparently is that currval(sequencename),
    > which is just nifty except the INSERT statement doesn't
    > say which field that is. Instead have I have to parse
    > out the table name and then look up in my own schema
    > definitions for which field that is.


    Take a look into the PG docu and search for:

    pg_get_serial_sequence(table_name, column_name)


    > So why does PostgreSQL suck? It's not that some people
    > decided they could make a better wheel than anyone else.
    > Maybe they could. But if I can't fit that wheel on the
    > existing waggon, it's useless pile of crap. It has got to
    > be obvious by this time that going from something like
    > Sqlite to PostgreSQL is going to be a bloody pain in the
    > butt because Postgres is so pure and blessed and above
    > the other databases that they cannot be botherred to provide
    > an interface that allows a programmer to use standard
    > query language and adapt an existing library interface
    > that behaves in a similar fashion for every database.


    Come on, stop complaining that you are not able to read
    the documentation.

    Beside this: starting with a Mysql implementation seems
    a bad idea to me.


    > One thing I've already learned is not depend on pg_%
    > tables to discover the schema, but to retain the schema
    > definition I used to create the database and parse that.


    You are right and wrong.
    Right in not using the pg_* tables, the information_schema
    exists, is clearly documented and this is a standard which
    even Mysql follows in never versions. Wrong in parsing your
    own stuff cause this stuff will change in every major version
    so you have to fix your application.


    Bye

    --
    Andreas 'ads' Scherbaum
    Explaining the concept of referential integrity to a mysql user is
    like explaining condoms to a catholic

  4. Re: Why PostgreSQL sucks.

    SM Ryan wrote:

    > It's not that some people decided they could make a better wheel than
    > anyone else. Maybe they could. But if I can't fit that wheel on the
    > existing waggon, it's useless pile of crap.


    Yeah. If you can't fit a SUV wheel on your cart, either the wheel or
    your cart is ****ty. What a conclusion ... I'd say, it just doesn't fit
    and this is not necessarily the wheel's problem.

    > I have learned too late that what I really need to do is
    > define a standard query language so that I can write the
    > bulk of my code independent of the databases.


    No, it seems you haven't learned that at all. If you want database
    independency, you use an abstraction layer. If this doesn't exist for
    your programming tool, the tool is not the right one for the task.

    > And yes I know what the S of SQL stands for, it's a lie and very poor
    > joke.


    Obviously you don't even know that, because it's "Structured Query
    Language". There is no "standard" in the name. But there are standards
    out there like SQL92, SQL99 and so on.

    So, what's the point of posting that crap here? Want to show, that
    you're not able to develop a database independant system?

    cug

+ Reply to Thread