Skip site navigation (1) Skip section navigation (2)

Re: Proposal: real procedures again (8.4)

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: Josh Berkus <Josh(dot)Berkus(at)sun(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>
Subject: Re: Proposal: real procedures again (8.4)
Date: 2007-10-30 14:33:19
Message-ID: 20071030143319.GB3352@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
James Mansion wrote:
> Josh Berkus wrote:
>> Not only would they be generally useful for SP programming, but
>> multisets would eliminate one of the big hurdles in re-writing T-SQL
>> stored procedures in PG, and thus make it easier to port from SQL
>> Server.  You don't hear a lot of demand for multisets on the mailing
>> lists because we're not getting those SQL Server / Sybase crossovers
>> now.
>>   
> Its true that multiple result sets are a big deal with T-SQL
> programming: but I think you'll also need to provide a way for the
> locking model to behave in a similar way and also very importantly to
> be able to emulate the after-statement triggers view of new and old
> images.

I don't think we need to (or, for that matter, are able to) change the
locking model, but the NEW and OLD views of for-statement triggers
should be just a SMOP.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-10-30 14:38:03
Subject: Re: install-strip causes dyld errors on OS X
Previous:From: Alvaro HerreraDate: 2007-10-30 14:31:12
Subject: Re: Proposal: real procedures again (8.4)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group