Re: external table - Mailing list pgsql-novice

From Albe Laurenz
Subject Re: external table
Date
Msg-id A737B7A37273E048B164557ADEF4A58B17D16F06@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Re: external table  ("John R. Sowden" <jsowden@americansentry.net>)
List pgsql-novice
John R. Sowden wrote:
> I write programs using the foxpro/dos language (I run them using
> ubuntu/dosemu).  It seems that the languages that I must write my
> database applications in, using pg apis, are c based.  In reading books
> on the issue, the quote that stands out in the first few pages is "if
> you understand c, then you won't have any problem learning ..."  I bout
> the kernigan 7 ritchie book in the 80s and decided that that is
> ridiculous, unless I wanted to get a job writing software.

There are PostgreSQL APIs for a lot of languages, including Perl, Java,
Python, .NET and many others.
They are not part of the PostgreSQL distribution, they are other open source
projects or commercial offerings.

Here is a good list:
http://www.postgresql.org/download/products/2-drivers-and-interfaces/

I doubt that anybody writes PostgreSQL applications in C.

> My programs are not just a list of queries and input forms.  One is an
> accounting program (GL) another is an AR/billing program, etc.
> 
> re: the external lookup table, I assume that I will more all of my dbf
> data to pg, not maintain a foreign table (foreign to pg). I am wondering
> how to create queries, etc. relating a table that is not inside the
> connected database.  I expect to have separate databases for gl,
> billing, dispatch, service call tracking.  Now each of these are
> separate tables (.dbf files).  These are not flat files, they are
> relational.

One PostgreSQL database can contain many tables.  You can organize these
in Schemas.

I would advise that you keep all tables that are used by one application
in one database. It is no problem if several applications access the
same database.

Since PostgreSQL 9.3 there is a foreign data wrapper (postgres_fdw) that
allows to access tables in different databases, but you should have a
really good reason for that, because it means a performance penalty,
complicates the architecture and does not guarantee that modifications
to both databases are atomic (i.e., it may happen that the transaction
succeeds in one database and fails in the other).

Yours,
Laurenz Albe

pgsql-novice by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: external table
Next
From: Rajmohan C
Date:
Subject: how to find the order of joins from Explain command XML plan output in PostgreSQL9.3.4