Re: maximum number of rows in table - what about oid limits?
От | Josh Berkus |
---|---|
Тема | Re: maximum number of rows in table - what about oid limits? |
Дата | |
Msg-id | web-69384@davinci.ethosmedia.com обсуждение исходный текст |
Ответ на | Re: maximum number of rows in table - what about oid limits? (Jonathan Bartlett <johnnyb6@sdf.lonestar.org>) |
Ответы |
Re: maximum number of rows in table - what about oid limits?
(Jonathan Bartlett <johnnyb6@sdf.lonestar.org>)
|
Список | pgsql-sql |
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 inthe 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 informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco
В списке pgsql-sql по дате отправления:
Предыдущее
От: Jonathan BartlettДата:
Сообщение: Re: maximum number of rows in table - what about oid limits?