Re: plpgsql vs. SQL in stored procedures

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: plpgsql vs. SQL in stored procedures
Date: 2004-03-31 11:07:56
Message-ID: 20040331130756.2cc03a1e@stige.webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Wed, 31 Mar 2004 03:31:01 -0500
Christopher Browne <cbbrowne(at)acm(dot)org> wrote:

> The forthcoming support for recursive queries using a WITH clause
> might provide, after a fashion, a way to declare variables.

I think I'll have to work with pg 7.3
Does this translate to: you won't be able to use variables?

I was used to do stuff like this with MS SQL

create proc sp_getuid @uid uniqueidentifier
as
delete from auth where lapse<dateadd(mi,-25,getdate())
declare @R_ID int

set @R_ID=(select R_ID from auth where
lapse>dateadd(mi,-10,getdate())
and A_ID=(at)uid)
if (@R_ID is null)
begin
delete from auth where A_ID=(at)uid
select null as R_ID
end
else
begin
update auth set lapse=getdate() where A_ID=(at)uid
select @R_ID as R_ID
end

Does it mean that to have variables in SP I'll have to use plpgsql
in spite of plain SQL?

> As for IF, there is a functional equivalent to it in the form of the
> SQL standard CASE statement.

TY for the refreshing pointer. I was looking in the wrong place.

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Richard Huxton 2004-03-31 12:06:04 Re: plpgsql vs. SQL in stored procedures
Previous Message Stephen Quinney 2004-03-31 10:41:27 Timestamp manipulation