(k)
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/INSERT-with-RETURNING-clause-inside-SQL-function-tp1923653p5445810.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
you can try:
CREATE OR REPLACE FUNCTION add_something(text, text)
RETURNS integer AS
$BODY$
DECLARE
somevariable integer;
BEGIN
INSERT INTO sometable (id, foo, bar ) VALUES (DEFAULT, $1, $2 ) RETURNING id
INTO somevariable;
return somevariable;
END;$BODY$ LANGUAGE 'plpgsql' VOLATILE;
--
View
On Tue, Nov 4, 2008 at 9:57 AM, Lennin Caro <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I'm re-writing some functions and migrating bussines
>> logic from a
>> client application to PostgreSQL.
>>
>> I expected something like this to work, but it doesn't:
>>
>> -- simple table
>> CREATE TABLE somet
> Hi all,
>
> I'm re-writing some functions and migrating bussines
> logic from a
> client application to PostgreSQL.
>
> I expected something like this to work, but it doesn't:
>
> -- simple table
> CREATE TABLE sometable (
>id SERIAL PRIMARY KEY,
>text1 text,
>text2 text
> );
>
>
On Tue, Nov 4, 2008 at 2:38 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Diego Schulz" <[EMAIL PROTECTED]> writes:
>> On Mon, Nov 3, 2008 at 10:24 PM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
>>> Just curious - what have you got against currval()? It seems to me that
>>> it would make your life e
"Diego Schulz" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 3, 2008 at 10:24 PM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
>> Just curious - what have you got against currval()? It seems to me that
>> it would make your life easier
> I simply don't like having to cast from BIGINT to INTEGER,
On Mon, Nov 3, 2008 at 8:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Diego Schulz" <[EMAIL PROTECTED]> writes:
>> I expected something like this to work, but it doesn't:
>
>> CREATE OR REPLACE FUNCTION add_something(text, text) RETURNS INTEGER AS $$
>>INSERT INTO sometable (id, foo, bar ) VAL
On Mon, Nov 3, 2008 at 10:24 PM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
> On 04/11/2008 01:20, Diego Schulz wrote:
>
>> I also tried this (somewhat silly) syntax to circumvent the issue
>> without resorting in currval:
>
> Just curious - what have you got against currval()? It seems to me tha
On 04/11/2008 01:20, Diego Schulz wrote:
> I also tried this (somewhat silly) syntax to circumvent the issue
> without resorting in currval:
Just curious - what have you got against currval()? It seems to me that
it would make your life easier
Ray.
-
"Diego Schulz" <[EMAIL PROTECTED]> writes:
> I expected something like this to work, but it doesn't:
> CREATE OR REPLACE FUNCTION add_something(text, text) RETURNS INTEGER AS $$
>INSERT INTO sometable (id, foo, bar ) VALUES (DEFAULT, $1, $2 )
> RETURNING id ;
> $$ LANGUAGE SQL ;
This case was
Forgot to mention: using 8.3.3 on FreeBSD.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi all,
I'm re-writing some functions and migrating bussines logic from a
client application to PostgreSQL.
I expected something like this to work, but it doesn't:
-- simple table
CREATE TABLE sometable (
id SERIAL PRIMARY KEY,
text1 text,
text2 text
);
CREATE OR REPLACE FUNCTION add_s
12 matches
Mail list logo
