From: | Jonathan Bartlett <johnnyb6(at)sdf(dot)lonestar(dot)org> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: maximum number of rows in table - what about oid limits? |
Date: | 2001-06-08 21:42:09 |
Message-ID: | Pine.LNX.4.21.0106082137460.5750-100000@sdf.lonestar.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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.
How exactly? The column types would just be INT8, right?
> 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.
>
Aha! The only thing I don't get is what do you mean by "execution state"?
(I'm guessing that you're not referring to Texas).
Jon
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2001-06-08 21:43:03 | Re: error starting postmaster |
Previous Message | Thalis A. Kalfigopoulos | 2001-06-08 21:23:02 | Re: Cleanly cancel a query. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-06-08 22:01:41 | Re: behavior of ' = NULL' vs. MySQL vs. Standards |
Previous Message | Josh Berkus | 2001-06-08 18:15:26 | Re: maximum number of rows in table - what about oid limits? |