PostgreSQL: Perl procedures with PL/pgSQL Part 2.

By Mark Nielsen

  1. Introduction
  2. Perl script to create tables, procedures, backup tables, and sequences.
  3. Executing the Perl script
  4. Considerations to explore.
  5. Conclusion
  6. References


After dealing with installing PostgreSQL, Perl, and embedding Perl in PostgreSQL, I wanted a standard way to create tables, sequences, stored procedures, and backup tables. Perhaps other people have nice GUI solutions to do this, but I haven't seen any. I would like it if someone would work with me to create a GUI interface to achieve what I am doing here. My goals are:
  1. Always backup data no matter what happens.
  2. Always use stored procedures to insert, update, delete, copy, or to do anything that changes data on the tables. One should even create stored procedures to select data.
  3. Have a Perl script create tables, sequences, backups tables, and the stored procedures to manipulate the data.
  4. Have the stored procedures clean data using Perl.
  5. Backup data if someone runs the Perl script on a live system.
  6. There should be an active column in the table so that you can specify active or inactive rows in the table. We create a view which views active rows of a table.
  7. Stored procedures should record date created and date last updated.
  8. All rows have a unique id. Even if we choose not to use them, they will still have them. It is not always good to use oid to get unique rows.
  9. Be able to delete inactive rows with a purge procedure. The delete procedure just makes it inactive. Also, unpurge data with the latest purged data for a unique id. This is cool.
  10. All negative numbers returned from pl/sql procedures are considered failures. All positive numbers (including 0) are considered to be successes in the fact nothing errored out. They are either 0, in which nothing happened, or something greater than 0 which indicates the number of items affected or a id number.
My future goals include:
  1. Creating a GUI interface. Preferrably one that is not dependent on GNOME or KDE libraries but Python. You can create Python binaries easily, so I would prefer Python/TK.
  2. Allow the GUI design to make changes to live tables by either:
  3. Record all database changes to review history.

Perl script to create tables, procedures, backup tables, and sequences.

Here is the Perl script I use. You can also get a copy here

Rename the perl script "". Here are the things needed to get it to work:

Executing the Perl script

You will need some more files. The Tables.txt file.

You can use my file as an example, but I suggest to modify it for your own needs. It is simulated to make three tables. One containing userame and passwords, and the other associating a username to a list of contacts. Another file you will need is

and lastly Custom.sql.

After you save the perl script, execute "chmod 755" and then "./". That should do it.

If you have installed PostgreSQL and Perl correctly, and you have setup the database and your account has permissions to that database, then everything should have worked fine.

Considerations to explore.

I would like to test TCL, Python, and other languages as well for stored procedures. If you are using MySQL, and I don't believe it has stored procedures, you may want to consider PostgreSQL if you like the style I mentioned. A nice GUI application to create tables and make changes to tables would be nice. Lastly, examples of how to connect to the database server to use these stored procedures (using Perl, Python, PHP, TCL, C, etc) would be nice.


The combination of PostgreSQL and Perl rocks. I can use Perl for three things, stored procedures, to setup my database, and to make Perl modules for Apache that connect to the PostgreSQL database. Similar stuff can be accomplished with other programming languages like Python, TCL, and others. I want to try Python at some point when it gets out of beta for PostgreSQL.

All database servers should use procedures exclusively for changing data. You could even argue that you should make custom stored procedures for selecting data as well. The reason why this is so important is because the web programmer (or other type of programmer) doesn't have to know anything about how to manipulate the data. They just submit variables to procedures. This lets the web programmer use any programming language he/she wants to without changing the behaviour of the database. The database and how you use it becomes abstract.

One stupid thing my perl script does is execute the custom sql code for each table. This s very bad. I will have to go back and fix it later. You may want to test my stuff out with these commands:

select sql_account_insert();
select sql_account_delete(1);
select sql_account_insert();
select sql_account_update(2,'mark','nielsen');
select sql_account_purge();
select sql_account_unpurge();
select * from account_backup;
select sql_account_delete(2);
select sql_account_insert();
select sql_account_update(1,'john','nielsen');
select sql_account_purge();
select * from account_backup;


  1. My Previous PostgreSQL article.
  2. If this article changes, it will be available here

Mark works as an independent consultant donating time to causes like, writing articles, writing free software, and working as a volunteer at

Copyright © 7/2001 Mark Nielsen