Re: Limitations on PGSQL - Mailing list pgsql-general

From Aasmund Midttun Godal
Subject Re: Limitations on PGSQL
Date
Msg-id 20011105111027.28816.qmail@ns.krot.org
Whole thread Raw
In response to Limitations on PGSQL  (Jean-Michel POURE <jm.poure@freesurf.fr>)
Responses Re: Limitations on PGSQL
List pgsql-general
IMHO Postgres' drawbacks are the following:

Severely limited access/grants system - postgres gives little or no control over anything beyond controlling access to
wholetables. -Yes you can create views but views have a couple of drawbacks too... This is especially a problem with
regardto functions (no trusted functions). 

Long connection time - if you are using the web you will have to use some sort of persistant scheme e.g. Apache::DBI
otherwiseyou will handle around 5 requests per sec on a decent computer. I wonder whether it would be possible for it
toeither reconnect, keeping the connection to a new database or user, or reuse it's kids - like Apache. 

No schema/tablespaces/cross-database access (- And it's listed on EXOTIC :()
- You can emulate some of these features yet it's not the same.

Error messages take a long time to get used to and generally figuring things out may take some time (at least for me)

If you create a function/trigger/view/rule etc. which accesses a table, and then you drop that table, and recreate it,
youmay have to recreate the function etc. 

It's advantages are:

Runs on practically any platform (I run OpenBSD so it matters).

Supports triggers, rules (statement level triggers), views and stored procedures!

fast - my queries - which may be quite complex at times, are generally fast, and if they are not I can always speed
themup with EXPLAIN, indexes, triggers creating derived tables and so on. 

Did I say stored procedures?

License - Do ANYTHING you want with it (more or less) not as communistic as the obiquitous GPL.

Price - Depending on your internet connection generally less than $0.02...

Great community - Does not mind answering questions and seems to forgive quickly as well.

Write Ahead logging, and many other functions I haven't really exploited yet.

Regards,

Aasmund




On Mon, 05 Nov 2001 11:33:48 +0100, Jean-Michel POURE <jm.poure@freesurf.fr> wrote:
> At 12:04 05/11/01 +0530, you wrote:
>
> Hello Balaji,
>
> There are no real limitations when using PostgreSQL smart programming
> features: views, triggers, rules, types and plpgsql server-side language.
>
> For example:
>
> 1) FAST READINGS: triggers can store display values instead of performing
> several LEFT JOINS or calling PL/pgSQL functions. Similarly, you can use
> triggers to perform complex initialization or maintain consistency when
> adding/modifying a record. Cron jobs and functions can perform queries and
> store results for instant results (ex: statistics tables).This makes your
> database very fast in complex readings (ex: web environment). This concept
> of storing values is the base of optimization.
> 2) SAFETY: postgreSQL is a real transactional system. When using a
> combination of views and rules, you can control data modification very
> neatly. Example: you can define a sub-select of a table and control the
> scope of queries. This is very important in a commercial environment when
> you data is valuable and must not be deleted or modified given a set of rules.
> 3) CODING: server-side coding is mainly performed in PL/pgSQL, a very easy
> and powerful server-side language.
>
> This is paradise if you are a programmer. IMHO, the only few drawbacks are:
>
> 1) TABLE DEFINITION: it is Impossible to delete a column or to
> promote/demote a column type. You have to drop the table and import old
> values into a new table. This makes life harder when working on large
> databases. You are always afraid of loosing your data. Even with backups,
> it is always 'heart breaking' to modify a table. You have to perform tests
> to ensure all data is there and safe.
>
> 2) VIEWS/TRIGGERS cannot be modified. You have to drop them and create them
> again. This makes programming a little bit tricky. Further more, if you
> create a view, let's say "SELECT table1.*, table2.* FROM table1 a LEFT JOIN
> table2 b on a.oid=b.oida", the resulting view displays all fields, hence
> making it harder for a non programmer to read view content.
>
> This is very little drawback compared to power and reliability of PostgreSQL.
>
> Best regards,
> Jean-Michel POURE
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Aasmund Midttun Godal

aasmund@godal.com - http://www.godal.com/
+47 40 45 20 46

pgsql-general by date:

Previous
From: Jean-Michel POURE
Date:
Subject: Limitations on PGSQL
Next
From: "Jeff Lu"
Date:
Subject: Re: Got error on CREATE TABLE AS (+Bug?)