No problem rick,
I'm actually very glad to hear that it's #2.
You wrote:
#2 is it generally, though the table's columns may need be extended over
time. So, is a "feature" a fixed-for-all-time schema or can it be extended
as a relational table can be?
The application is gathering data from monitoring stations. Stations may
have some variations in what data are provided, and station design may
evolve over time. A feature based on a relational table with columns that
are the union of all available data seems like a good fit, with unused cells
filled with "missing data". This might depend on the availability of a
"missing data" value in WFS transactions.
You've got the right idea here. Geoserver does a couple of things, but one thing that it does is act as a "web front-end" to a PostGIS table (that is, a postgres table that is 'spatially enabled' by the PostGIS postgres add-on). Geoserver will then handle the insertion, deletion, modifcation and query of that table via OGC standard XML messages. These messages (defined in the Web Feature Service or "WFS" specification) are not SOAP, nor are they standard XML-RPC messages...but they are "standard" in that they are well-known and decently documented.
Since geoserver acts as a 'web front-end' to this table, you can actually change the table behind the scenes all that you want. As long as it's a working PostGIS table, you should be all set. When you make changes to the table, you may need to 'reconfigure' geoserver in order to make everything work together just right, but I don't think there will generally be a problem with extending the table in the future.
In addition, PostGIS will allow you to create spatial 'views' where you join together two or more tables into a view, one or more columns of which are 'spatial' columns. This is the only mechanism by which geoserver can directly draw data from two tables at the same time, so if your queries are going to be based on any sort of joins between tables, you'll need to think this part through ahead of time.
Here's a basic run-down of what you'll need to do to get geoserver up and running.
1) Install postgres, and postGIS
2) Properly create and register a 'spatial' table with the columns you want, in the database.
3) Install Java (version 1.4.2 or higher, although 1.5 will give you significant performance improvements)
4) Download and start up geoserver (either in a seperate servlet container or using the built-in 'jetty' container)
5) Using the geoserver web-ui, configure a "datasource" to your running postGIS instance
6) Using the geoserver web-ui, configure a 'featuretype' based on the table you created in step 2
7) Learn enough about the WFS specification to start querying (or inserting) data from (or into) the featuretype you've created in step 6. This will involve sending XML messages via POST to geoserver...take a look at 'wget' or 'curl' for your debugging sessions.
8) Add the functionality you develop in step 7 to a program so that you can have this all done automatically. You can use any major programming language, and you can also use javascript (and other browser-based languages) or even command-line UNIX based scripts.
Good luck! Keep us in the loop on your progress.
--saul