Hello
I send my first patch for PostgreSQL - maybe ugly patch. This patch
generate on top of dump file line with setting of current encoding. Its
useful for languages like czech with more than one wide used encoding.
We need informations about used encoding.
Regards
Pavel Stehule
51a52,53
trap_exceptions
-
(1 row)
DROP FUNCTION
Regards,
Pavel Stehule
--
-- Test of built variables SQLERRM and SQLCODE
--
create or replace function trap_exceptions() returns void as $_$
begin
begin
raise exception 'first exception';
exception when others then
raise
I think we discussed this last year and decided that it would be a bad
idea to use those names because Oracle's use of them is not exactly
compatible with our error codes and messages. SQLCODE in particular is
not compatible at all --- it's an integer in Oracle, isn't it?
There is more
to plpgsql_block and have local scope. Default values are
'0' for SQLCODE and 'Sucessful completion' for SQLERRM. Some example
of using is in file test.sql.
Regards
Pavel Stehule
--
-- Test of built variables SQLERRM and SQLCODE
--
create or replace function trap_exceptions() returns void as $_$
begin
are
'0' for SQLSTATE and 'Sucessful completion' for SQLERRM.
Regards
Pavel Stehule
*** test.old/plpgsql.sql2005-02-22 08:18:27.0 +0100
--- test/plpgsql.sql2005-03-08 09:58:23.419281208 +0100
***
*** 1917,1920
create function void_return_expr() returns
Hello,
I am not sure, I corrected memory problems, I think, but there are some
changes in plpgsql code. I'l update patch today.
Regards
Pavel Stehule
On Mon, 18 Apr 2005, Bruce Momjian wrote:
Guys, is this patch ready for application? I think so, but am not 100%
sure
value specified by the SQL standard,
replaced SQLCODE years ago (SQL-92?). Perhaps both Oracle and DB2/2
have support for it.
But I didn't find good informations about error trapping in ANSI SQL. All
informations are about Oracle or DB2 :-(.
Best Regards
Pavel Stehule
://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/functions/months_between.htm
Best regards
Pavel Stehule
diff -c -r --new-file pgsql.old/doc
Hello
I am sorry, this mail contains doc for execute into
Regards
Pavel Stehule
*** pgsql.old/doc/src/sgml/plpgsql.sgml 2005-04-19 05:55:43.0 +0200
--- pgsql.new/doc/src/sgml/plpgsql.sgml 2005-06-01 19:28:51.0 +0200
***
*** 1251,1263
On Fri, 3 Jun 2005, Neil Conway wrote:
Pavel Stehule wrote:
http://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/functions
way to
implemented its efective like normal contrib functions. And if they are
outside main tree, you have to maintain patch :-(.
I expect so less used functions will go to contrib: LNNVL, .. but some
functions can by general usefull. There is WIDTH_BUCKET in core too now.
Who use it?
Pavel
Hello
I have new version. I'll send it early.
Regards
Pavel Stehule
On Sat, 4 Jun 2005, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL
* from fx where 1 = 0 limit 1),
null,current_timestamp::timestamp(0);
end; $$ language plpgsql;
CREATE FUNCTION
pokus=# select x();
NOTICE: sss 23:00:00 1 root {10,20,30} 2005-06-13 07:06:07.43569+02 10
NULL NULL 2005-06-13 07:
06:07
Regards
Pavel Stehule
diff -c -r --new-file pgsql.00/doc
On Mon, 13 Jun 2005, Michael Glaesemann wrote:
On Jun 13, 2005, at 2:07 PM, Pavel Stehule wrote:
I did trivial patch which eliminate limit raise command. Using
expressions instead of variables are a little bit expensive, but
little.
I'm right in thinking this essentially does
-in or previously
defined exception name, this is probably workable from a syntactic point
of view.
Pavel Stehule
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
state (no from me:), but maybe is usefull
for test. The moust important is posibility handling own exception without
parsing SQLERRMS, I think. Setting SQLSTATE is usefull for
interoperatibility between procedures and throwing system errors.
Regards
Pavel Stehule
diff -c -r --new-file src.00
Why not compromise? Allow ONLY \' in normal strings? That'd deal with
the majority of compatibility issues. Or, like you say, make it a GUC :(
Chris
what is wrong on GUC?
Pavel
---(end of broadcast)---
TIP 6: Have you searched our
.
---
Pavel Stehule wrote:
Hello
This patch contains three oracle users missing functions. But I
hope can be usefull for all PostgreSQL users (users vote me ;-) Certainly
LEAST and GREATEST, which has not analogy. Using of DECODE is similar
CASE, but with some
this patch is last
Pavel
On Tue, 21 Jun 2005, Bruce Momjian wrote:
Pavel Stehule wrote:
Hello,
I sended version with only LEAST and GREATEST
http://archives.postgresql.org/pgsql-patches/2005-06/msg00185.php
this patch contains diff files for NEXT_DAY and LAST_DAY function too
Done
Regards
Pavel Stehule
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Mon, 4 Jul 2005, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
I'll review and apply this in the next day or so.
Have we got a consensus yet on the behavior? There seemed to be no
meeting
exception variable in the first place. What does it buy us over simply
using a string? In other words, if we allowed the syntax:
RAISE LEVEL [ opt_sqlstate ] 'fmt' [, expr ... ]
where `opt_sqlstate' is either empty, a T_WORD we find in the table of
predefined condition names, or an
This would require promoting all the options for LEVEL into fully
reserved words. You really can't get around the fact that you need
something pretty identifiable to terminate the expression.
It might work to require parentheses:
RAISE LEVEL ( sqlstate expression ), 'fmt' [, ...]
On Wed, 6 Jul 2005, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
if I use registered sqlstate, plpgsql knows text message.
No, it does not. I already pointed out that tying a single error
message to a SQLSTATE is unreasonable, because that's not how the
SQL committee intended
I really don't like the idea of introducing a new concept into the
language (exception variables) to resolve some ambiguous syntax. It
would be another matter if exception variables actually provided
something that strings do not...
In this time e.variables does it - only holds
On Fri, 8 Jul 2005, Neil Conway wrote:
Neil Conway wrote:
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition), or a TEXT
variable. If users need to throw a sqlstate that is derived from a SQL
expression, they can
On Fri, 8 Jul 2005, Neil Conway wrote:
Pavel Stehule wrote:
ok, but don't forget, please, on exception part.
What do you mean?
-Neil
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
Pavel
---(end of broadcast
On Fri, 8 Jul 2005, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
BTW, do have we reached a consensus on this?
Doesn't look that way --- I tend to agree with you that we could avoid
inventing declared exceptions at all, but Pavel is definitely not happy
with it, and AFAIR no one
cancel commnd
security key isn't possible
I hope PostgreSQL will support both variants in future.
I invite any notes, suggestions
Regards
Pavel Stehule
Welcome to psql 8.1devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
good idea. it's what can eliminate not neccessery using plperl. I would to
see it in plpgsql.
regards
Pavel
On Thu, 14 Jul 2005, Titus von Boxberg wrote:
Hi all,
I needed introspection capabilities for record types to write more generic
trigger procedures in PL/PGSQL.
With the
On Tue, 26 Jul 2005, Neil Conway wrote:
Neil Conway wrote:
Not at the moment. I believe we have agreed that it would be better to
remove the concept of exception variables and just use strings, but I
haven't implemented this yet.
BTW, one minor annoyance I noticed: a builtin condition
hello,
sorry, exception variables don't solve this problem too. But we can detect
it in compile-time. I don't wont to complicate raise syntax.
best regards
Pavel
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
pg_catalog.fast_cstring_concat (
BASETYPE = cstring,
SFUNC = xmlagg_trans,
STYPE = text,
FINALFUNC = xmlagg_final);
I invite all notes, ..
Best regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http
hope SQL/XML syntax is
exception and the solution SQL/XML function is relative clean. There was
ideas about pretranslators from different syntaxs. Is this idea dead?
regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger
Hello
this patch allow using any row or record expression in return, return next
statement in row, record functions - per request John Berkus
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01350.php
regards
Pavel Stehule
From: Neil Conway [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] return can contains any row or record functions
Date: Mon, 07 Nov 2005 18:10:13 -0500
I'm confused by this part of the patch, circa line 1835 of pl_exec.c
- we can't use estate-rsi for the RETURN case, at least as presently
implemented, because that is not always filled-out -- the example I gave
before shows how because we don't check for a compatible TupleDesc when
estate-rsi is NULL, we end up returning a value that is incompatible
with the
Hello
small patch, add form is not distinct from expression (sql2003)
regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
diff -c -r pgsql.old/doc/src/sgml/func.sgml
;
-- or --
for r in select * from data loop
x, y := r;
return next;
end loop;
return;
end; $$ language plpgsql;
This patch allow using qualified identifiers in fore and fors stmts too.
Best regards
Pavel Stehule
_
Najdete si svou lasku
Pavel Stehule [EMAIL PROTECTED] writes:
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
It's same as select into or execute into (using same code). And behave is
like row variable := row variable. I am
Tom Lane said:
Pavel Stehule [EMAIL PROTECTED] writes:
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
Where does the idea come from anyway? Has it been discussed on -hackers? I
don't recall seeing it. Just
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
Could use PHP-style thingy:
LIST(x, y) := r;
Chris
It's inconsystency :-(.
EXECUTE INTO and SELECT INTO use scalar of vectors without anything.
Pavel
Pavel Stehule [EMAIL PROTECTED] writes:
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
Could use PHP-style thingy:
LIST(x, y) := r;
Actually, ROW(x, y) would be the right spelling per SQL convention.
I am
Hello
I cut controvers support for assign stmt. This patch is only
enhancing fore and fors stmts.
Regards
Pavel Stehule
_
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
diff -c -r pgsql/doc/src
I wonder if we should try to consistently treat an INSERT/UPDATE/DELETE
with a RETURNING clause like a SELECT with an equivalent target list.
For example, should it be possible to write:
FOR x in DELETE FROM t1 WHERE ... RETURNING t1.x LOOP
...
END LOOP;
Or open a cursor for a
Hello
this small patch allow use sql for creating wrappers others void functions.
Currently void SQL function have to be empty.
create or replace function foo(int) returns void as ' ','' language c ..;
create or replace function foo() returns void as $$ select foo(10);
$$language sql;
Hello
this small patch allow use sql for creating wrappers others void
functions.
Currently void SQL function have to be empty.
create or replace function foo(int) returns void as ' ','' language c
..;
create or replace function foo() returns void as $$ select foo(10);
$$language
Hello
This patch add functionality USING to all EXECUTE statements.
Regards
Pavel Stehule
_
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
---(end of broadcast
Hello
This patch add functionality USING to all EXECUTE statements.
Regards
Pavel Stehule
p.s. again with patch :-)
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
execute_using.dif
Description: Binary
PostgreSQL
don't support it. But it's the moust faster way for generating XML files,
10x faster then PHP or Perl. Please look again on this patch. I am not sure
about solution without ANSI compatibility.
Regards
Pavel Stehule
don't. Is this XML patch a major missing thing? No idea.
We don't need export XML. I need XML directly from database. I understand so
this patch add some rows to server, but it's save thousands lines on client
sides. Every AJAX or .NET scripts can use it.
Regards
Pavel Stehule
inside recursion or outside.
2. Some people use my patch. Without my patch there will be more request for
it.
Best regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz
Not from my side
Regards
Pavel Stehule
From: Bruce Momjian pgman@candle.pha.pa.us
To: Pavel Stehule [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], pgsql-patches@postgresql.org
Subject: Re: [PATCHES] return can contains any row or record functions
Date: Wed, 14 Jun 2006 18:48:00 -0400 (EDT)
Has
functions
http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
---
Pavel Stehule wrote:
Not from my side
Regards
Pavel Stehule
From: Bruce Momjian pgman@candle.pha.pa.us
To: Pavel Stehule [EMAIL
Hello,
I send two small patches. First does conversion from perl to postgresql
array in OUT parameters. Second patch allow hash form output from procedures
with one OUT argument.
Regards
Pavel Stehule
_
Citite se osamele
.
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
---(end of broadcast)---
TIP 4: Have you searched our list archives
regards
Pavel Stehule
Pavel Stehule wrote:
There are some problems about replacing string values in the SQL
string.
Doesn't the Oracle implementation already imply a solution to that?
I don't know. I didn't find any detail documentation about it. I don't
know
what Oracle exactly do
Hello,
this patch allow any expression in return statement and it does simply
casting from non type record into typed records. Allows same casting as
assign statement.
Regards
Pavel Stehule
From: Bruce Momjian [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: [EMAIL PROTECTED
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http
Hello
I am sending corrected version.
regards
Pavel Stehule
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.
---
Pavel Stehule
Pavel Stehule [EMAIL PROTECTED] writes:
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns
Hello,
This patch allow use TM prefix in to_char functions for czech environment.
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
*** ./src/backend/po/cs.po.orig
Hello,
this patch correct bug in to_char function with incorrect uppercased month's
or day's name.
Regards
Pavel Stehule
_
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
*** ./src/backend/utils/adt
Hello,
this patch adds scrollable support functions to SPI. It's necessary for
scrollable cursors in plpgsql. Original API is without changes.
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http
Neil Conway [EMAIL PROTECTED] writes:
BTW, how do people feel about the function names:
SPI_cursor_open_with_options
SPI_scroll_cursor_fetch
SPI_scroll_cursor_move
I dislike the SPI_cursor_open_with_options API on the grounds that it
lets people break things (CURSOR_OPT_HOLD for
Pavel Stehule [EMAIL PROTECTED] writes:
if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is
cheap
(not when is possible). It's true?
Nope. If you want a scrollable plan you need to make sure you tell the
planner about it. SPI_cursor_open is not in charge, it's merely
Pavel Stehule [EMAIL PROTECTED] writes:
if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is
cheap
(not when is possible). It's true?
Nope. If you want a scrollable plan you need to make sure you tell the
planner about it. SPI_cursor_open is not in charge, it's merely
Hello,
I am working on new version. Old patch doesn't solve scrollability well.
Regards
Pavel Stehule
Where are we on this patch?
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
if I comprehended
Hello
this patch contains ansi sql scrollable cursors's support for plpgsql. Add
three function to SPI and plpgsql scrollable cursor sup. is first test app
of this functionality.
Regards
Pavel Stehule
_
Citite se osamele
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Would you please modify this patch to use the functions in
oracle_compat.c?
---
Pavel Stehule wrote:
Hello,
this patch correct bug in to_char
This short patch is too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
This short patch is too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
This short patch was too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Hello,
I am sorry for preview chotic mails. My web email client is stupid (I am
too).
This patch correct bug, when localized day or month names was incorectly
trnasformed to lower or upper string.
Regards
Pavel Stehule
Patch applied. Thanks.
I have not backpatched it to 8.2.X because I am unclear of the risk
involved. Suggestions?
It's bug in 8.2. I don't know about any risks for 8.2
Pavel
---
Pavel Stehule wrote:
Pavel
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
Regards
Pavel
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes
Pavel Stehule wrote:
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
I can update and send
functions
Description: SIGMOD Record, Vol. 33, No. 1, March 2004
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
*** ./doc/src/sgml/plpgsql.sgml.orig 2007-02-11 12:01
:
http://forums.oracle.com/forums/thread.jspa?threadID=467278tstart=0
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
*** ./src/backend/utils/adt/datetime.c.orig 2007
Pavel Stehule [EMAIL PROTECTED] writes:
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same
to
USE_ISO_DATESTYLE. Differences are for timestamp:
ISO: -mm-dd hh24:mi:ss
XSD: -mm-ddThh24
I'm not sure that we are actually guaranteeing anything about XML validity
against any schema or DTD, are we?
what?
ofcourse you cannot garant validity against any schema. But mapping
functions are standardised and expect xsd. And I what I can meet protocols
based on xml, they respect xsd
On Tue, Feb 20, 2007 at 04:32:28PM +0100, Pavel Stehule wrote:
I am sorry. I reported this two times before. This patch is related only
for xml functionality. XSD datestyle is only one internal constant.
There
are no new datestyle (I hope so can be usefull). My patch is small bug
fix
like
From: Andrew Dunstan [EMAIL PROTECTED]
To: Peter Eisentraut [EMAIL PROTECTED]
CC: Pavel Stehule [EMAIL PROTECTED],
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] correct format for date, time, timestamp for XML
functionality
Date: Tue, 20 Feb 2007 11:37:31 -0500
Peter Eisentraut
Pavel Stehule [EMAIL PROTECTED] writes:
this patch contains function ArmorCustomVariables. This function set
flag
armored on any custom variable. From this moment only superuser can
change
this variable.
Why is this a good idea? Why don't you just fix the problem as
previously agreed
This is the most recent email I have on this. Was the scrollable patch
applied? If not, would you resubmit?
I resubmit scrollable cursor patch
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi
://archives.postgresql.org/pgsql-hackers/2007-03/msg01487.php
link to patch: http://www.pgsql.cz/patches/plpgpsm.diff.gz
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz
.
Regards
Pavel Stehule
From: Bruce Momjian [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: pgsql-patches@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCHES] simply custom variables protection
Date: Sat, 7 Apr 2007 11:54:13 -0400 (EDT)
Pavel, would you remind me how
safely modify
custom variables.
---
Regards
Pavel Stehule
From: Bruce Momjian [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: pgsql-patches@postgresql.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject
, which is surely not desirable.
I don't protect this patch. I didn't understand original proposal well.
Tom, I don't understand your last notice. Can you explain it, please.
Pavel Stehule
_
Citite se osamele? Poznejte nekoho
are table attributies (not variables) and then we are protected before
collision. It's shortcut for
create function foo() returns setof record as ...
select * from foo() as (x int, y int);
Regards
Pavel Stehule
_
Najdete si svou
are table attributies (not variables) and then we are protected before
collision. It's shortcut for
create function foo() returns setof record as ...
select * from foo() as (x int, y int);
Regards
Pavel Stehule
_
Najdete si svou
-defined_Routines_and_Object_Behavior.pdf
Regards
Pavel Stehule
From: Tom Lane [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [PATCHES] Table function support Date: Tue, 10 Apr 2007
18:17:14 -0400
Pavel Stehule [EMAIL PROTECTED] writes:
this patch allows
On Wed, 2007-03-28 at 17:42 +0200, Pavel Stehule wrote:
This is the most recent email I have on this. Was the scrollable patch
applied? If not, would you resubmit?
I resubmit scrollable cursor patch
I notice your patch has been accepted, though admit I hadn't noticed it
previously
Hello
I refreshed Magnus's patch
http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
februar.
Regards
Pavel Stehule
p.s. scrollable cursors in plpgsql need little work still. I forgot for
nonstandard (postgresql extension) direction forward all, forward n,
backward n
and if we support
MOVE FORWARD ... then is logic support MOVE FORWARD n ,
else FORWARD, BACKWARD are nonstandard and MOVE statement too.
Regards
Pavel Stehule
_
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http
Hello,
I actualised sql/psm patch:
added:
* last Tom's plpgsql patches (some fixes and enum support)
* scrollable cursor's support
new version is on http://www.pgsql.cz/patches/plpgpsm0501.diff.gz
Regard
Pavel Stehule
Your patch has been added to the PostgreSQL unapplied patches list
and simple tool for it.
Older version was broken by enum patch and scrollable cursor patch.
Older version didn't dump table functions correctly. It's fixed now.
Regards
Pavel Stehule
*** ./pg_dump.c.orig 2007-05-06 11:13:11.0 +0200
--- ./pg_dump.c 2007-05-06 11:16:53.0 +0200
Do we have a patch to make this consistent?
no, not yet. It's topic for discussion and ToDo
Regards
Pavel Stehule
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
Hello
I am not sure, but your solution will faill on scrollable cursors
(it's similar to holdable cursors). I miss part about limits in
documentation. Propably updatable cursors aren't supported by plpgsql
(and it's point to ToDo).
Regards
Pavel Stehule
2007/5/17, FAST PostgreSQL [EMAIL
:-)
Rgds,
Arul Shaji
Pavel Stehule wrote:
Hello
I am not sure, but your solution will faill on scrollable cursors
(it's similar to holdable cursors). I miss part about limits in
documentation. Propably updatable cursors aren't supported by plpgsql
(and it's point to ToDo).
Regards
Pavel
1 - 100 of 177 matches
Mail list logo
