On Thu, Sep 30, 2004 at 07:06:10AM +0100, PostgreSQL Bugs List wrote:
>
> The problem happens when I was trying the example that is described in
> "PostgreSQL 8.0.0beta1 Documentation, chapt 33.4 --- A Complete Example".
>
> At the last step, as the document says, the result should be:
> => DEL
Neil Conway <[EMAIL PROTECTED]> writes:
> ... One way to fix this would be to reimplement EXECUTE to
> be essentially `eval': it would take an arbitrary string and execute it
> as a PL/pgSQL statement. That would fix the FOUND problem, and also give
> us EXECUTE INTO in one fell swoop.
Yeah, this
On Fri, 2004-10-01 at 13:39, Tom Lane wrote:
> Possibly not. Can EXECUTE determine how the executed statement would
> have set the flag?
At the moment, EXECUTE just feeds the string it finds to spi_execute().
We could probably hack it to figure out how to modify FOUND, but I think
it would be ugl
On Fri, 2004-10-01 at 13:46, Tom Lane wrote:
> We specifically do not require a semicolon at the very end of the
> function definition.
Yeah, makes sense. Attached is a doc patch. Barring any objections I'll
apply it to HEAD by end-of-day today.
-Neil
Index: doc/src/sgml/plpgsql.sgml
===
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-10-01 at 01:11, Hussein Patni wrote:
>> I noticed in plpgsql that a semi colon is not always requiredafter
>> the END statement.
> Yeah, I've noticed this as well (although it doesn't appear to be
> documented). Would we gain anything by enfor
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-10-01 at 02:26, Tom Lane wrote:
>> EXECUTE does not set the FOUND flag.
> Is there a good reason for this behavior?
Possibly not. Can EXECUTE determine how the executed statement would
have set the flag? Should we assume that the function d
On Fri, 2004-10-01 at 02:26, Tom Lane wrote:
> EXECUTE does not set the FOUND flag.
Is there a good reason for this behavior?
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs
On Fri, 2004-10-01 at 01:11, Hussein Patni wrote:
> I noticed in plpgsql that a semi colon is not always requiredafter
> the END statement.
Yeah, I've noticed this as well (although it doesn't appear to be
documented). Would we gain anything by enforcing this restriction? IMHO
not a lot...
-Neil
Rami,
there is not even a small chance that the admin-restriction will be
dropped within windows. All arguments have been discussed in detail,
and the decision has been made to not drop it by the very core
developers.
You do know of the "runas" command within XP? That helps you in
testing, you ca
=?koi8-r?B?68/O09TBztTJzg==?= <[EMAIL PROTECTED]> writes:
> sql := 'insert into tbl' || suffix::text || ' values (1,1)';
> EXECUTE sql;
> IF NOT FOUND THEN
> RAISE NOTICE 'NOT INSERTED';
> END IF;
EXECUTE does not set the FOUND flag. See
http://developer.postgresql.org/docs/postgres/plpgsql-sta
Hello,
FreeBSD, I386, Postgres 8.0.0 beta2
Trying issuing such a plpgsql function:
Create function test_fun (suffix char(4)) returns integer as $$
DECLARE
sql text;
BEGIN
sql := 'insert into tbl' || suffix::text || ' values (1,1)';
EXECUTE sql;
IF NOT FOUND THEN
RAISE NOTICE 'NOT INSERTED';
END I
Hello,
I noticed in plpgsql that a semi colon is not always required after
the END statement. A contrived example:
CREATE sequence foo;
CREATE OR REPLACE FUNCTION bar() RETURNS VOID AS '
DECLARE
bar int;
BEGIN
SELECT INTO bar nextval(''foo'');
RETURN;
END
' LANGUAGE plpgsql;
--hussein
Ð ÐÑÐ, 29.09.2004, Ð 11:39, PostgreSQL Bugs List ÐÐÑÐÑ:
Read:
> creating template1 database in C:/PGSQL80/data/base/1 ... execution of
> PostgreSQL by a user with administrative permissions is not permitted.
> The server must be started under an unprivileged user ID to prevent
> possible system
13 matches
Mail list logo
