Re: [PATCHES] plpython improvements
Sven Suursoho wrote: Hi, Quoting Bruce Momjian [EMAIL PROTECTED]: Great. Please supply documentation and it will be applied. Thanks. Here it comes, including src+doc patches. Updated sources according to Michael Fuhr's comments and fixed one FIXME. Please check documentation patch thoroughly as I'm not native English speaker nor didn't manage to generate documentation from SGML sources ( openjade:postgres.sgml:3:55:W: cannot generate system identifier for public text -//OASIS//DTD DocBook V4.2//EN) Patch applied. Thanks. I improved your documentation wording, updated version attached. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/plpython.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v retrieving revision 1.30 diff -c -c -r1.30 plpython.sgml *** doc/src/sgml/plpython.sgml 26 May 2006 19:23:09 - 1.30 --- doc/src/sgml/plpython.sgml 2 Sep 2006 12:12:40 - *** *** 46,67 titlePL/Python Functions/title para !Functions in PL/Python are declared via the usual xref linkend=sql-createfunction endterm=sql-createfunction-title !syntax. For example: programlisting ! CREATE FUNCTION myfunc(text) RETURNS text ! AS 'return args[0]' ! LANGUAGE plpythonu; /programlisting The Python code that is given as the body of the function definition !gets transformed into a Python function. !For example, the above results in programlisting ! def __plpython_procedure_myfunc_23456(): ! return args[0] /programlisting assuming that 23456 is the OID assigned to the function by --- 46,95 titlePL/Python Functions/title para !Functions in PL/Python are declared via the standard xref linkend=sql-createfunction endterm=sql-createfunction-title !syntax: ! ! programlisting ! CREATE FUNCTION replaceablefuncname/replaceable (replaceableargument-list/replaceable) ! RETURNS replaceablereturn-type/replaceable ! AS $$ ! # PL/Python function body ! $$ LANGUAGE plpythonu; ! /programlisting ! /para ! ! para !The body of a function is simply a Python script. When the function !is called, all unnamed arguments are passed as elements to the array !varnameargs[]/varname and named arguments as ordinary variables to the !Python script. The result is returned from the Python code in the usual way, !with literalreturn/literal or literalyield/literal (in case of !a resultset statement). ! /para ! ! para !For example, a function to return the greater of two integers can be !defined as: ! programlisting ! CREATE FUNCTION pymax (a integer, b integer) ! RETURNS integer ! AS $$ ! if a gt; b: ! return a ! return b ! $$ LANGUAGE plpythonu; /programlisting The Python code that is given as the body of the function definition !is transformed into a Python function. For example, the above results in programlisting ! def __plpython_procedure_pymax_23456(): ! if a gt; b: ! return a ! return b /programlisting assuming that 23456 is the OID assigned to the function by *** *** 69,74 --- 97,257 /para para +The productnamePostgreSQL/ function parameters are available in +the global varnameargs/varname list. In the +functionpymax/function example, varnameargs[0]/varname contains +whatever was passed in as the first argument and +varnameargs[1]/varname contains the second argument's value. Alternatively, +one can use named parameters as shown in the example above. This greatly simplifies +the reading and writing of applicationPL/Python/application code. + /para + + para +If an SQL null valueindextermprimarynull value/primarysecondary +sortas=PL/PythonPL/Python/secondary/indexterm is passed to a +function, the argument value will appear as symbolNone/symbol in +Python. The above function definition will return the wrong answer for null +inputs. We could add literalSTRICT/literal to the function definition +to make productnamePostgreSQL/productname do something more reasonable: +if a null value is passed, the function will not be called at all, +but will just return a null result automatically. Alternatively, +we could check for null inputs in the function body: + + programlisting + CREATE FUNCTION pymax (a integer, b integer) + RETURNS integer + AS $$ + if (a is None) or (b is None): + return None + if a b: + return a + return b + $$ LANGUAGE plpythonu; + /programlisting + +As shown above, to return an SQL null value from a PL/Python +function, return the value symbolNone/symbol. This can be done whether the +function is strict or not. + /para + + para +Composite-type arguments are passed to the
Re: [HACKERS] [PATCHES] Resurrecting per-page cleaner for
Tom, should I apply this patch now? Are you still considering other options for this? --- Bruce Momjian wrote: Tom, I ran your tests with fsync off (as you did), and saw numbers bouncing between 400-700 tps without my patch, and sticking at 700 tps with my patch. --- Bruce Momjian wrote: The attached patch requires the new row to fit, and 10% to be free on the page. Would someone test that? --- Tom Lane wrote: ITAGAKI Takahiro [EMAIL PROTECTED] writes: This is a revised patch originated by Junji TERAMOTO for HEAD. [BTree vacuum before page splitting] http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php I think we can resurrect his idea because we will scan btree pages at-atime now; the missing-restarting-point problem went away. I've applied this but I'm now having some second thoughts about it, because I'm seeing an actual *decrease* in pgbench numbers from the immediately prior CVS HEAD code. Using pgbench -i -s 10 bench pgbench -c 10 -t 1000 bench (repeat this half a dozen times) with fsync off but all other settings factory-stock, what I'm seeing is that the first run looks really good but subsequent runs tail off in spectacular fashion :-( Pre-patch there was only minor degradation in successive runs. What I think is happening is that because pgbench depends so heavily on updating existing records, we get into a state where an index page is about full and there's one dead tuple on it, and then for each insertion we have * check for uniqueness marks one more tuple dead (the next-to-last version of the tuple) * newly added code removes one tuple and does a write * now there's enough room to insert one tuple * lather, rinse, repeat, never splitting the page. The problem is that we've traded splitting a page every few hundred inserts for doing a PageIndexMultiDelete, and emitting an extra WAL record, on *every* insert. This is not good. Had you done any performance testing on this patch, and if so what tests did you use? I'm a bit hesitant to try to fix it on the basis of pgbench results alone. One possible fix that comes to mind is to only perform the cleanup if we are able to remove more than one dead tuple (perhaps about 10 would be good). Or do the deletion anyway, but then go ahead and split the page unless X amount of space has been freed (where X is more than just barely enough for the incoming tuple). After all the thought we've put into this, it seems a shame to just abandon it :-(. But it definitely needs more tweaking. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Resurrecting per-page cleaner for
Bruce Momjian [EMAIL PROTECTED] writes: Tom, should I apply this patch now? Are you still considering other options for this? Please wait. This issue is very far down the to-list in terms of size or significance ... but I'll get to it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pgstattuple extension for indexes
Patch applied. Thanks.
I updated the README documentation for the new functions, attached. I
could not update the Japanese version of the README.
---
Satoshi Nagayasu wrote:
Bruce,
Attached patch has been cleaned up,
and modified to be able to work with CVS HEAD.
Thanks.
Satoshi Nagayasu wrote:
Alvaro,
Alvaro Herrera wrote:
Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD:
/pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function
'GetBTPageStatistics':
/pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c:182: error:
'BTItem' undeclared (first use in this function)
While you're at it, please consider removing C++ style comments and
unused code.
Formatting is way off as well, but I guess that is easily fixed with
pgindent.
Thanks for comments. I'm going to fix my patch from now.
Regarding the pg_relpages function, why do you think it's necessary?
(It returns the true number of blocks of a given relation). It may
belong into core given a reasonable use case, but otherwise it doesn't
seem to belong into pgstatindex (or pgstattuple for that matter).
I wanted to sample some pages from the table/index, and get their statistics
to know table/index conditions. I know pgstattuple() reports table
statistics, however, pgstattuple() generates heavy CPU and I/O load.
When we need to sample some pages from table/index, we need to know
true number of blocks.
I have another function, called pgstatpage(), to get information inside
a single block/page statistics of the table. pg_relpages() will be used
with this.
Sorry for not mentioned in previous post about pgstatpage(),
but I've remembered about it just now.
Many memories in my brain have already `paged-out` (too busy in last few
months),
and some of them got `out-of-memory`. :^)
Thanks.
--
NAGAYASU Satoshi [EMAIL PROTECTED]
Phone: +81-3-3523-8122
diff -ruN pgstattuple.orig/Makefile pgstattuple/Makefile
--- pgstattuple.orig/Makefile 2006-02-27 21:54:40.0 +0900
+++ pgstattuple/Makefile 2006-08-14 09:28:58.0 +0900
@@ -6,7 +6,7 @@
#
#-
-SRCS = pgstattuple.c
+SRCS = pgstattuple.c pgstatindex.c
MODULE_big = pgstattuple
OBJS = $(SRCS:.c=.o)
diff -ruN pgstattuple.orig/pgstatindex.c pgstattuple/pgstatindex.c
--- pgstattuple.orig/pgstatindex.c1970-01-01 09:00:00.0 +0900
+++ pgstattuple/pgstatindex.c 2006-08-14 11:24:23.0 +0900
@@ -0,0 +1,706 @@
+/*
+ * pgstatindex
+ *
+ * Copyright (c) 2006 Satoshi Nagayasu [EMAIL PROTECTED]
+ *
+ * Permission to use, copy, modify, and distribute this software and
+ * its documentation for any purpose, without fee, and without a
+ * written agreement is hereby granted, provided that the above
+ * copyright notice and this paragraph and the following two
+ * paragraphs appear in all copies.
+ *
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT,
+ * INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
+ * LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
+ * DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN AS
+ * IS BASIS, AND THE AUTHOR HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
+ * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
+ */
+
+#include postgres.h
+
+#include fmgr.h
+#include funcapi.h
+#include access/heapam.h
+#include access/itup.h
+#include access/nbtree.h
+#include access/transam.h
+#include catalog/namespace.h
+#include catalog/pg_type.h
+#include utils/builtins.h
+#include utils/inval.h
+
+PG_FUNCTION_INFO_V1(pgstatindex);
+PG_FUNCTION_INFO_V1(bt_metap);
+PG_FUNCTION_INFO_V1(bt_page_items);
+PG_FUNCTION_INFO_V1(bt_page_stats);
+PG_FUNCTION_INFO_V1(pg_relpages);
+
+extern Datum pgstatindex(PG_FUNCTION_ARGS);
+extern Datum bt_metap(PG_FUNCTION_ARGS);
+extern Datum bt_page_items(PG_FUNCTION_ARGS);
+extern Datum bt_page_stats(PG_FUNCTION_ARGS);
+extern Datum pg_relpages(PG_FUNCTION_ARGS);
+
+#define PGSTATINDEX_TYPE public.pgstatindex_type
+#define PGSTATINDEX_NCOLUMNS 10
+
+#define BTMETAP_TYPE public.bt_metap_type
+#define BTMETAP_NCOLUMNS 6
+
+#define BTPAGEITEMS_TYPE public.bt_page_items_type
+#define BTPAGEITEMS_NCOLUMNS 6
+
+#define BTPAGESTATS_TYPE public.bt_page_stats_type
+#define BTPAGESTATS_NCOLUMNS 11
+
+
+#define IS_INDEX(r) ((r)-rd_rel-relkind == 'i')
+#define IS_BTREE(r) ((r)-rd_rel-relam == BTREE_AM_OID)
+
+#define CHECK_PAGE_OFFSET_RANGE(page, offset) { \
Re: [PATCHES] better support of out parameters in plperl
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
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.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params. But
names are optional, as I understand it. Arguably, we should be treating the
returns positionally, and thus return an arrayref when there are OYT params,
not a hashref, and ignore the names - after all, all perl function args are
nameless, in fact, even if you use a naming convention to refer to them.
Fourth, I don't understand the change: allow hash form output from
procedures with one OUT argument. That seems very non-orthogonal, and I
can't see any good reason for it.
Lastly, if you look at the expected output as committed,it appears to have
been prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on
July 28th, which was probably much too late given some of the issues. Unless
we can solve these issues very fast I would be inclined to say this should be
tabled for 8.3. I think this is a fairly good illustration of the danger of
springing a feature, largely undiscussed, on the community just about freeze
time.
cheers
andrew
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Custom variable class segmentation
Where are we on the GUC comment/reload to defaults patch? Do we have multiple people objecting to its application? Previously only Tom objected, and Andrew partially. --- Bruce Momjian wrote: Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: The latest HEAD is segfaulting on startup if I have the following lines in postgresql.conf: custom_variable_classes = 'plperl' plperl.use_strict = on Bruce, please re-revert that GUC patch and don't put it back in until someone like Peter or me has actually reviewed it. My faith in it has gone to zero, and I don't think you are able to fix it either. Peter had already reviewed it and given comments. There were three things wrong with the original patch: o spacing, e.g. if( x =- 1 ) o an incorrect API for memory freeing by parse_value() o verify_config_option() didn't consider custom variables These have all been corrected, so I don't see the value in removing the patch now that it is working. I have attached the three GUC patches that were applied to CVS, so if someone wants corrections or removal based on specific issues, please let me know. BTW, do I need to mention that the plperl patch is breaking the buildfarm again? That has been reverted, because of the regression failures and Andrew's analysis. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Patch for - Change FETCH/MOVE to use int8
Patch applied. Thanks. I had to convert a lot of whitespace to tabs. It wasn't just the whitespace, but whitespace that was 8 spaces. I assume you are reading our code using an 8-space tab. Please see the developer's FAQ and try to use tabs in future patches. Thanks. --- Dhanaraj M wrote: Hi Alvaro Thanks for your valuable suggestions. I made the changes as suggested earlier. Please review again and comment on this. I like to make changes if it is required. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] extension for sql update
Susanne Ebrecht wrote:
Is it too hard to rip it back out once the full row support
arrives? That seems speculation at best anyway.
That's what I was thinking. Glad someone else replied. ;-)
If you're looking for votes, +1. I'll gladly take a subset of the
SQL standard UPDATE table SET (...) = (...) over having nothing.
+1 here, too. :)
+1
I am working now to get this into 8.2.
I am glad to read this. But what does it mean to me? Shall I change the
patch someway?
I have merged your patch into current CVS and applied it; attached.
There was quite a bit of code drift. One drift area was the new
RETURNING clause; that was easy to fix. A more complex case is the
code no longer has values as ResTargets --- it is a simple a_expr list,
so I changed the critical assignment in gram.y from:
res_col-val = (Node *)copyObject(res_val-val);
to:
res_col-val = (Node *)copyObject(res_val);
Hope that is OK. Without that fix, it crashed. I also merged your SGML
syntax and grammer addition into the exiting UPDATE main entry.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/update.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v
retrieving revision 1.38
retrieving revision 1.39
diff -c -r1.38 -r1.39
*** doc/src/sgml/ref/update.sgml 12 Aug 2006 02:52:03 - 1.38
--- doc/src/sgml/ref/update.sgml 2 Sep 2006 20:34:47 - 1.39
***
*** 21,27
refsynopsisdiv
synopsis
UPDATE [ ONLY ] replaceable class=PARAMETERtable/replaceable [ [ AS ] replaceable class=parameteralias/replaceable ]
! SET replaceable class=PARAMETERcolumn/replaceable = { replaceable class=PARAMETERexpression/replaceable | DEFAULT } [, ...]
[ FROM replaceable class=PARAMETERfromlist/replaceable ]
[ WHERE replaceable class=PARAMETERcondition/replaceable ]
[ RETURNING * | replaceable class=parameteroutput_expression/replaceable [ AS replaceable class=parameteroutput_name/replaceable ] [, ...] ]
--- 21,28
refsynopsisdiv
synopsis
UPDATE [ ONLY ] replaceable class=PARAMETERtable/replaceable [ [ AS ] replaceable class=parameteralias/replaceable ]
! [ SET replaceable class=PARAMETERcolumn/replaceable = { replaceable class=PARAMETERexpression/replaceable | DEFAULT } [, ...] |
! SET ( replaceable class=PARAMETERcolumn/replaceable [, ...] ) = ( { replaceable class=PARAMETERexpression/replaceable | DEFAULT } [, ...] ) [, ...] ]
[ FROM replaceable class=PARAMETERfromlist/replaceable ]
[ WHERE replaceable class=PARAMETERcondition/replaceable ]
[ RETURNING * | replaceable class=parameteroutput_expression/replaceable [ AS replaceable class=parameteroutput_name/replaceable ] [, ...] ]
***
*** 251,256
--- 252,261
UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
WHERE city = 'San Francisco' AND date = '2003-07-03';
/programlisting
+ programlisting
+ UPDATE weather SET (temp_lo, temp_hi, prcp) = (temp_lo+1, temp_lo+15, DEFAULT)
+ WHERE city = 'San Francisco' AND date = '2003-07-03';
+ /programlisting
/para
para
Index: src/backend/parser/gram.y
===
RCS file: /cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.560
retrieving revision 2.562
diff -c -r2.560 -r2.562
*** src/backend/parser/gram.y 2 Sep 2006 18:17:17 - 2.560
--- src/backend/parser/gram.y 2 Sep 2006 20:52:01 - 2.562
***
*** 237,243
name_list from_clause from_list opt_array_bounds
qualified_name_list any_name any_name_list
any_operator expr_list attrs
! target_list update_target_list insert_column_list
values_list def_list indirection opt_indirection
group_clause TriggerFuncArgs select_limit
opt_select_limit opclass_item_list
--- 237,244
name_list from_clause from_list opt_array_bounds
qualified_name_list any_name any_name_list
any_operator expr_list attrs
! target_list update_col_list update_target_list
! update_value_list set_opt insert_column_list
values_list def_list indirection opt_indirection
group_clause TriggerFuncArgs select_limit
opt_select_limit opclass_item_list
***
*** 308,314
%type jexpr joined_table
%type range relation_expr
%type range relation_expr_opt_alias
! %type target target_el update_target_el insert_column_item
%type typnam Typename SimpleTypename ConstTypename
GenericType Numeric opt_float
--- 309,316
%type jexpr joined_table
%type range relation_expr
%type range relation_expr_opt_alias
! %type target target_el update_target_el update_col_list_el insert_column_item
! %type list update_target_lists_list
Re: [PATCHES] [Fwd: dblink patch - Asynchronous queries and parallel
Joe Conway wrote: Sorry for the delay. I've done some rework to the original code sent by Kai, mainly to reduce duplication with the existing synchronous case, and to better fit with the existing docs, regression script, etc. I also changed the return type of dblink_get_connections() to text[], and added dblink_error_message(). If it isn't already too late, and there are no objections, I'd like to commit this in the next day or so. Patch applied. Joe ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Concurrent connections in psql patch
Is this something people are interested in? I am thinking no based on the lack of requests and the size of the patch. --- Gregory Stark wrote: Andrew Dunstan [EMAIL PROTECTED] writes: stark wrote: So I hacked psql to issue queries asynchronously and allow multiple database connections. That way you can switch connections while a blocked or slow transaction is still running and issue queries in other transactions. [snip] Can you please put the patch up somewhere so people can see what's involved? As promised: [ Attachment, skipping... ] -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] proposal - plpgsql: execute using
So the patch is being withdrawn by the author? OK.
---
Pavel Stehule wrote:
Hello,
This task can be better solved. There are some problems with strings, but
bigger problem is impossibility to pass nonscalar variables. What is
questions? Does Oracle allow variables on nonparam positions? If not, then I
see more elegant solution via preprocessed statements.
Best 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.
Oracle does use USING:
EXECUTE IMMEDIATE dynamic_string
[INTO {define_variable[, define_variable]... | record}]
[USING [IN | OUT | IN OUT] bind_argument
[, [IN | OUT | IN OUT] bind_argument]...]
[{RETURNING | RETURN} INTO bind_argument[, bind_argument]...];
so I think we are OK there.
I think we'd be best off to leave EXECUTE alone, at least until we've
converged to the point where almost nobody is using
non-standard-compliant
strings.
Maybe, but patch have to solve SQL string and non SQL strings too
The only case I see you using it is for \:. What is the purpose of
that? Can't we use :: for a literal :?
I have attached the patch from March.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
execute_using.dif
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Use of backslash in tsearch2
Thanks. Yes, it is need for two reasons. In 8.2 you can set standard_conforming_strings to on, meaning \' is really treated as \ and ', and because some encodings now can't support \' for security reasons, though I don't think tsearch2 supports those multibyte encodings. Anyway, applied to 8.2 only, not backpatched. Thanks. --- Teodor Sigaev wrote: Patch isn't full, simple test (values are took from regression.diffs): and try dump table and restore: ERROR: syntax error CONTEXT: COPY tt, line 5, column tq: '1 ''2' Attached cumulative patch fixes problem, but I have some doubts, is it really needed? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ [ application/x-tar is not supported, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Backend SSL configuration enhancement
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Victor B. Wagner wrote: On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote: Victor B. Wagner [EMAIL PROTECTED] writes: This patch adds two new configuration diretives to postgresql.conf file 1. ssl_ciphers - allows server administrator to specify set of SSL ciphersuites which can be used by clients to connect the server. 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware crypto accelerator support) to use. Why are either of these useful? What are the compatibility implications First one is useful if for some reason some ciphers supported by OpenSSL is not permitted to use in the particular network, or if there is need to use ciphersuites which are not included into default ciphersuite list, now compiled into PostgreSQL. It might be requirement of enhanced security, or some national standards requirement. Or vice versa - people might want client certificates for authentication, but avoid encryption for performance reasons. Second one can be used for taking cryptography load from server into special hardware chip, which can be useful for loaded servers. Also, upcoming OpenSSL 0.9.9 allows to add entirely new cryptographic algorithms via engines, so engine support allows to use algorithms, i.e. national standards, which are not supported in the OpenSSL core. We have developed this patch in order to use Russian GOST algorithms for SSL connections. of changing them? Does the addition of the engine-load code break compatibility with older OpenSSL releases? Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already supports them. So, compatibility is broken only with 0.9.6 and eariler which have numerous other problems anyway. I can recheck my patch and add conditional compilation around engine loading code to be sure that it doesn't break compatiblity with 0.9.6, just ignores ssl_engine keyword if underlying OpenSSL doesn't support engines. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote: Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. The OIDs may be useful to people inspecting pg_depend, for example; but then, it's foolish not to be using regclass in that case. Whether a table is bootstrap or not doesn't seem useful to me. Something that might be handy would be a method to determine if an object is a system object or not (perhaps what the OP means by bootstrap). We spent quite some time figuring out how to handle that when we were working on newsysviews. In that case, we wanted the info because it's handy to be able to query a view that's not cluttered up with a bunch of system-defined stuff. Having a way to get a list of only user-defined functions, for example. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] extension for sql update
bruce wrote: I have merged your patch into current CVS and applied it; attached. There was quite a bit of code drift. One drift area was the new RETURNING clause; that was easy to fix. A more complex case is the code no longer has values as ResTargets --- it is a simple a_expr list, so I changed the critical assignment in gram.y from: res_col-val = (Node *)copyObject(res_val-val); to: res_col-val = (Node *)copyObject(res_val); Hope that is OK. Without that fix, it crashed. I also merged your SGML syntax and grammer addition into the exiting UPDATE main entry. The copyObject() is not required. Removed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [COMMITTERS] pgsql: Change FETCH/MOVE to use int8.
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Log Message:
---
Change FETCH/MOVE to use int8.
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for 2gig tables.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/tcop/pquery.c
===
RCS file: /cvsroot/pgsql/src/backend/tcop/pquery.c,v
retrieving revision 1.108
diff -c -c -r1.108 pquery.c
*** src/backend/tcop/pquery.c 2 Sep 2006 18:17:17 - 1.108
--- src/backend/tcop/pquery.c 3 Sep 2006 01:13:20 -
***
*** 1347,1353
* we are. In any case, we arrange to fetch the target row
* going forwards.
*/
! if (portal-posOverflow || portal-portalPos == LLONG_MAX ||
count - 1 = portal-portalPos / 2)
{
DoPortalRewind(portal);
--- 1347,1353
* we are. In any case, we arrange to fetch the target row
* going forwards.
*/
! if (portal-posOverflow || portal-portalPos == FETCH_ALL ||
count - 1 = portal-portalPos / 2)
{
DoPortalRewind(portal);
Index: src/include/nodes/parsenodes.h
===
RCS file: /cvsroot/pgsql/src/include/nodes/parsenodes.h,v
retrieving revision 1.327
diff -c -c -r1.327 parsenodes.h
*** src/include/nodes/parsenodes.h 2 Sep 2006 18:17:17 - 1.327
--- src/include/nodes/parsenodes.h 3 Sep 2006 01:13:22 -
***
*** 14,19
--- 14,21
#ifndef PARSENODES_H
#define PARSENODES_H
+ #include limits.h
+
#include nodes/primnodes.h
#include nodes/value.h
***
*** 1439,1445
--- 1441,1452
FETCH_RELATIVE
} FetchDirection;
+ #ifdef HAVE_INT64
#define FETCH_ALL LLONG_MAX
+ #else
+ #define FETCH_ALL LONG_MAX
+ #endif
+
typedef struct FetchStmt
{
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] better support of out parameters in plperl
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at the last moment. Pavel needs to get into the habit of
submitting ideas first, not just patches. And there must be proper
documentation and working regression tests.
cheers
andrew
Bruce Momjian wrote:
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
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.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params. But
names are optional, as I understand it. Arguably, we should be treating the
returns positionally, and thus return an arrayref when there are OYT params,
not a hashref, and ignore the names - after all, all perl function args are
nameless, in fact, even if you use a naming convention to refer to them.
Fourth, I don't understand the change: allow hash form output from procedures with
one OUT argument. That seems very non-orthogonal, and I can't see any good reason
for it.
Lastly, if you look at the expected output as committed,it appears to have been
prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on July
28th, which was probably much too late given some of the issues. Unless we can
solve these issues very fast I would be inclined to say this should be tabled
for 8.3. I think this is a fairly good illustration of the danger of springing
a feature, largely undiscussed, on the community just about freeze time.
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] better support of out parameters in plperl
OK.
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Dunstan wrote:
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at the last moment. Pavel needs to get into the habit of
submitting ideas first, not just patches. And there must be proper
documentation and working regression tests.
cheers
andrew
Bruce Momjian wrote:
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
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.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params.
But names are optional, as I understand it. Arguably, we should be
treating the returns positionally, and thus return an arrayref when there
are OYT params, not a hashref, and ignore the names - after all, all perl
function args are nameless, in fact, even if you use a naming convention
to refer to them.
Fourth, I don't understand the change: allow hash form output from
procedures with one OUT argument. That seems very non-orthogonal, and I
can't see any good reason for it.
Lastly, if you look at the expected output as committed,it appears to have
been prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on
July 28th, which was probably much too late given some of the issues.
Unless we can solve these issues very fast I would be inclined to say this
should be tabled for 8.3. I think this is a fairly good illustration of
the danger of springing a feature, largely undiscussed, on the community
just about freeze time.
cheers
andrew
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] better support of out parameters in plperl
Oh, let me add that this was first discussed on July 28:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php
and a patch posted on July 30:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php
---
Andrew Dunstan wrote:
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at the last moment. Pavel needs to get into the habit of
submitting ideas first, not just patches. And there must be proper
documentation and working regression tests.
cheers
andrew
Bruce Momjian wrote:
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
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.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params.
But names are optional, as I understand it. Arguably, we should be
treating the returns positionally, and thus return an arrayref when there
are OYT params, not a hashref, and ignore the names - after all, all perl
function args are nameless, in fact, even if you use a naming convention
to refer to them.
Fourth, I don't understand the change: allow hash form output from
procedures with one OUT argument. That seems very non-orthogonal, and I
can't see any good reason for it.
Lastly, if you look at the expected output as committed,it appears to have
been prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on
July 28th, which was probably much too late given some of the issues.
Unless we can solve these issues very fast I would be inclined to say this
should be tabled for 8.3. I think this is a fairly good illustration of
the danger of springing a feature, largely undiscussed, on the community
just about freeze time.
cheers
andrew
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] SSL enhancement patch ver.2
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Victor B. Wagner wrote: This patch adds following functionality to PostgreSQL 1. If PostgreSQL is compiled with OpenSSL version 0.9.7 and above, both backend and libpq read site-wide OpenSSL configuration file as described in OPENSSL_config functon manual page. This allows to use hardware crypto acceleration modules (engines) and, in future version 0.9.9 would allow to use additional cryptoalgorithms (i.e. national standards) which are not included in core OpenSSL. All other configuration parameters which are supported by OpenSSL library also are taken into account. 2. New configuration option ssl_ciphers is added to postgresql.conf. This option allows to change list of ciphers, acceptable by backend during SSL connection. Changing list of ciphers can be desirable to tighten or relax security of particular installation, and allows quick fix on configuration file level in case if vulnerability is discovered in one of cryptoalgorithms or their OpenSSL implementation - cipher suites which use such algorithm can be easily disabled. 3. If libpq compiled with OpenSSL 0.9.7 and above, compiled with engine support, it is possible to store secret key of client certificate on the hardware token, supported by one of OpenSSL engines (Hardware Security Module). Name of engine which supports token and engine-specific key ID are specifyed using environment variable PGSSLKEY. This allows use of hardware tokens such as smartcards to identify clients, connecting to database. This functionality can be used in installations with high security requirements or in situations where several people can use same terminal (such as cash register in shops or malls). If PostgreSQL is compiled with version of OpenSSL which do not support engines or doesn't have OPENSSL_config function, related functionality is excluded by preprocessor conditionals, based on value of SSLEAY_VERSION_NUMBER preprocessor symbol which is defined by all versions of OpenSSL. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [DOCS] Predicate Locking
Peter Eisentraut wrote: David Fetter wrote: This patch clarifies the 'predicate locking' section in the docs. What it does it raise the question what next-key locking is. I don't think any of this matters for us. We should just remove the part that claims that no other system implements predicate locking. OK, new text is: For these reasons, productnamePostgreSQL/productname does not implement predicate locking. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] better support of out parameters in plperl
Like I said, at the last moment.
Bruce Momjian wrote:
Oh, let me add that this was first discussed on July 28:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php
and a patch posted on July 30:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php
---
Andrew Dunstan wrote:
I think it has to wait to 8.3. It's a complete mess that was submitted
unheralded at the last moment. Pavel needs to get into the habit of
submitting ideas first, not just patches. And there must be proper
documentation and working regression tests.
cheers
andrew
Bruce Momjian wrote:
Uh, were are we in fixing/reviewing this?
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
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.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params. But
names are optional, as I understand it. Arguably, we should be treating the
returns positionally, and thus return an arrayref when there are OYT params,
not a hashref, and ignore the names - after all, all perl function args are
nameless, in fact, even if you use a naming convention to refer to them.
Fourth, I don't understand the change: allow hash form output from procedures with
one OUT argument. That seems very non-orthogonal, and I can't see any good reason
for it.
Lastly, if you look at the expected output as committed,it appears to have been
prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on July
28th, which was probably much too late given some of the issues. Unless we can
solve these issues very fast I would be inclined to say this should be tabled
for 8.3. I think this is a fairly good illustration of the danger of springing
a feature, largely undiscussed, on the community just about freeze time.
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] [COMMITTERS] pgsql: Change FETCH/MOVE to use int8.
Bruce Momjian [EMAIL PROTECTED] writes: This patch has broken half the buildfarm, and I've still not seen a rationale why we need to make such a change at all. Fixed with attached patch. The use case for this was not FETCH, but MOVE for 2gig tables. There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD ALL does not need this to work for 2G tables). It is not worth the extra computational cycles that it imposes on every machine whether they use the feature or not, and it is certainly not worth the developer time we're expending to fix this poorly written patch. Please revert it. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] [COMMITTERS] pgsql: Change FETCH/MOVE
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: This patch has broken half the buildfarm, and I've still not seen a rationale why we need to make such a change at all. Fixed with attached patch. The use case for this was not FETCH, but MOVE for 2gig tables. There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD ALL does not need this to work for 2G tables). It is not worth the extra computational cycles that it imposes on every machine whether they use the feature or not, and it is certainly not worth the developer time we're expending to fix this poorly written patch. Please revert it. Already done because of bad coding. You want the TODO item removed too? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Patch for - Change FETCH/MOVE to use int8
bruce wrote:
Patch applied. Thanks.
I had to convert a lot of whitespace to tabs. It wasn't just the
whitespace, but whitespace that was 8 spaces. I assume you are reading
our code using an 8-space tab. Please see the developer's FAQ and try
to use tabs in future patches. Thanks.
I have reverted this patch. It was causing crashes in the ecpg
regression tests. I think the problem was in scan.l:
+ /* For Fetch/Move stmt, convert the string into int64
value */
+ if (strcmp(yylval.keyword, fetch) == 0 ||
+ strcmp(yylval.keyword, move) == 0)
+ {
+ int64 int64Val;
+ errno = 0;
This is code that was in the 'integer' section. Why did you think you
could compare a non-assigned yylval at this stage? Anyway, this isn't
going into 8.2.
---
Dhanaraj M wrote:
Hi Alvaro
Thanks for your valuable suggestions.
I made the changes as suggested earlier.
Please review again and comment on this.
I like to make changes if it is required.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] plpgsql, return can contains any expression
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 wrote: 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://messenger.msn.cz/ [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Jim C. Nasby [EMAIL PROTECTED] writes: On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote: Whether a table is bootstrap or not doesn't seem useful to me. Something that might be handy would be a method to determine if an object is a system object or not (perhaps what the OP means by bootstrap). No, what the OP meant by bootstrap is one of the four core BKI_BOOTSTRAP catalogs, and the reason they're so core is that bootstrap mode itself doesn't really work till they exist. (I agree with Alvaro that by the time you get interested in what BKI_BOOTSTRAP does, you probably don't need to have any hand-holding from catalogs.sgml; you're already at least an apprentice wizard.) But ever since 7.3 the convention for identifying system objects has been pretty well-defined: anything that lives in one of the predefined schemas. What problem were you having using that approach in newsysviews? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] better support of out parameters in plperl
Bruce Momjian [EMAIL PROTECTED] writes: Uh, were are we in fixing/reviewing this? It's dead for 8.2 --- Andrew's complaints are pretty serious at both the conceptual and implementation levels, and there's been no sign of discussion about how to fix them. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] [COMMITTERS] pgsql: Change FETCH/MOVE to use int8.
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD ALL does not need this to work for 2G tables). Already done because of bad coding. You want the TODO item removed too? As I said, I see no use case for it. Maybe if Moore's Law holds up for another five or ten years, it'll look like a useful feature then ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
