Limitations on PGSQL

From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: pgsql-general(at)postgresql(dot)org
Cc: balaji(dot)venkatesan(at)megasoft(dot)com
Subject: Limitations on PGSQL
Date: 2001-11-05 10:33:48
Message-ID: 4.2.0.58.20011105102300.00d065d0@pop.freesurf.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

At 12:04 05/11/01 +0530, you wrote:
>Hi,
> Can someone plz to do specify the features and more important the
> limitations in using
>PostgreSQL. More info regarding performace etc shall be of immense help
>Regards
>Bv :-)

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Patrick 2001-11-05 11:06:29 Define update-rule on view
Previous Message tony 2001-11-05 09:23:10 Function problems redux

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrea Aime 2001-11-05 11:03:23 Re: Serious performance problem
Previous Message Zeugswetter Andreas SB SD 2001-11-05 09:47:57 Re: Beta going well