Re: maximum number of rows in table - what about oid limits?

Jon,

> The nice thing about OIDs is that if you ever need to merge rows, you
> could make a function that searched all OID-type parameters and
> change the
> old reference to the new one.

The same thing can be done with the 'universal_sq' approach.

> Were I doing PostgreSQL for a business, I most assuredly would.
> However,
> I am currently just toying around with creating a common set of base
> tables that would be useful in almost any application, taking
> advantage of
> PostgreSQL's specific capabilities. However, I asked the question
> because
> if the only real problem is compatibility, I might be able to do it
> myself (or maybe not).

Great! Go for it. Personally, I lack the knowledge ...

> Agreed, but if people are going to take PostgreSQL seriously, then
> some
> of the top limits need to be expanded.

Expanding the top limits is obviously a Good Thing (tm). However, I
point out that expanding the top limits may not be the highest priority
for PostgreSQL development (of course, it may be). Row limits are
mainly important to web apps.

For the kind of app I do (accounting and reporting) things like stored
procedures, nested transaction handling, full support for ALTER TABLE,
etc., are a *lot* more important than OID/TXN limits. Plus some more
administrative interface projects, and an updated version of PGAccess.

It's my opinion that PostgreSQL has a lot more to gain in terms of
market acceptance as an application database server than a web database
server. In the web arena, PostgreSQL must compete against MySQL and
Oracle which are quite good; in medium-sized database applications, the
only competition is MS SQL Server. PostgreSQL is *already* better than
MSSQL, but it's going to have to be *much* better before people will
notice it. IMHO.

> You could probably find a college student to do whatever you wanted
> for a
> grand.

Hey, if you know anyone, please have them e-mail me.

> Out of curiosity, what do you mean by "Real Stored Procedures"?

Since you're undoubtedly familiar with PostgreSQL functions, I will list
only how a stored procedure differes from a PgSQL function:

1. Is precompiled, with a saved plan of execution on the server.
(not sure about the wisdom of this but it appears to be in the SQL 99
standard)
2. Can return a rowset or multiple rowsets
3. Accepts an indefinite number of parameters
4. Returns an execution state and none to many return values
5. Supports full server control internally, depending on language; thus
SQL and PL/pgSQL procedures should support cursors, locak handling,
transactions and database control language.

I'm not sure that all of the above is in the standard; the text on
Stored Procedures in SQL 99 seems to be somewhat skimpy, the committee
perhaps leaving it up to te vendors to implement (pfaugh!) but all of
the above is consistent with Stored Procedure implementation in MS SQL
Server 7 and Oracle 8.

-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh(at)agliodbs(dot)com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco