Re: [HACKERS] [PATCHES] Latest Turkish translation updates
Wow, Turkish seem to be the first translation to report 100% translation completion for 8.0 release. Congratulations for great work! And thanks to Peter for being patient with us all this time. > > We can't reproduce it with msgfmt -v. How do you get those errors? > > The scripts that produce these tables do not use the standard gettext > tools; they use hand-crafted Perl scripts. In some cases, these catch > more errors. In all cases that I have analyzed further, this was > because %m was not identified as a format specifier by msgfmt. Could you share these scripts with us? Many update submissions we made were beacause of these %m errors. Also would it be easier to you Peter if we give you login to our CVS poject (on sf.net) so that you just run "cvs up" every time you package a new update and not bother with emails. Thank you all folks for your efforts. I will open a bottle of chamgne tonight to celebrate 8.0. > Peter Eisentraut > http://developer.postgresql.org/~petere/ Best regards, Nicolai Tufar ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Spanish translation updates
Alvaro Herrera wrote: > Attached is a round of spanish translation updates which would take > it to 100% again. Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Bag-over-head patch (was Re: [PATCHES] PL/Perl doc patch)
On Sun, Jan 16, 2005 at 10:06:09PM -0500, Bruce Momjian wrote:
>
> Patch applied. Thanks. Your documentation changes can be viewed in
> five minutes using links on the developers page.
Bruce, thanks.
Please find enclosed another patch that now (I hope) really is
correct. It's in addition to the previous patch.
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Index: doc/src/sgml/plperl.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.36
diff -c -r2.36 plperl.sgml
*** doc/src/sgml/plperl.sgml17 Jan 2005 03:04:17 - 2.36
--- doc/src/sgml/plperl.sgml17 Jan 2005 17:12:34 -
***
*** 543,564
! @{$_TD->{argv}}
!Arguments of the trigger function
! $_TD->{argc}
!Number of arguments of the trigger function
--- 543,565
! $_TD->{argc}
!Number of arguments of the trigger function
! @{$_TD->{args}}
!Arguments of the trigger function. Does not exist if $_TD->{argc}
is 0.
+
---(end of broadcast)---
TIP 3: 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: Bag-over-head patch (was Re: [PATCHES] PL/Perl doc patch)
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, http://www.postgresql.org/developer/testing. --- David Fetter wrote: > On Sun, Jan 16, 2005 at 10:06:09PM -0500, Bruce Momjian wrote: > > > > Patch applied. Thanks. Your documentation changes can be viewed in > > five minutes using links on the developers page. > > Bruce, thanks. > > Please find enclosed another patch that now (I hope) really is > correct. It's in addition to the previous patch. > > Cheers, > D > -- > David Fetter [EMAIL PROTECTED] http://fetter.org/ > phone: +1 510 893 6100 mobile: +1 415 235 3778 > > Remember to vote! [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
Цитирую Oleg Bartunov : > Hi there, > > I just completed russian translation of .po files ( except > ru.po for backend ). > diff against rc3 is available from > http://www.sai.msu.su/~megera/postgres/docs/ru.po-8.0.0.rc3.diff.gz Thanks Oleg for taking care of it while I am away! Here's last minute backend translation: http://www.cs.concordia.ca/~serguei/postgres-ru.po It's not 100%, but all fuzzy messages are gone and some common agreed-on terminology fixes are in (for archives: foreign key, relation, and a few others). Please-please-please apply :) -s > Oleg > > On Thu, 6 Jan 2005, Serguei Mokhov wrote: > > > - Original Message - > > From: "Peter Eisentraut" <[EMAIL PROTECTED]> > > Sent: January 06, 2005 3:48 AM > > > >> Am Mittwoch, 5. Januar 2005 05:38 schrieb Oleg Bartunov: > >>> Serguei, I have translations (I didn't touch libpq, psql in work, > >>> other files seems complete) available from > >>> http://www.sai.msu.su/~megera/oddmuse/ > >> > >> Let me know when you have something finished and ready to commit. > > > > Will be in soon. > > > > -s > > > > Regards, > Oleg > _ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
Serguei Mokhov wrote: > Here's last minute backend translation: Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
Цитирую Peter Eisentraut <[EMAIL PROTECTED]>: > Serguei Mokhov wrote: > > Here's last minute backend translation: > > Installed. Dear Peter, please, last things: a few new messages in the below were translated and a couple of typos fixed. Now these all are 100%: http://www.cs.concordia.ca/~serguei/initdb-ru.po http://www.cs.concordia.ca/~serguei/pg_config-ru.po http://www.cs.concordia.ca/~serguei/pg_ctl-ru.po http://www.cs.concordia.ca/~serguei/psql-ru.po http://www.cs.concordia.ca/~serguei/pg_dump-ru.po Thank you! -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
On Mon, 17 Jan 2005, Serguei Mokhov wrote: > Date: Mon, 17 Jan 2005 20:58:38 + > > > Here's last minute backend translation: > > > > Installed. > > Dear Peter, please, last things: a few new messages in the below were > translated > and a couple of typos fixed. Now these all are 100%: > > http://www.cs.concordia.ca/~serguei/initdb-ru.po > http://www.cs.concordia.ca/~serguei/pg_config-ru.po > http://www.cs.concordia.ca/~serguei/pg_ctl-ru.po > http://www.cs.concordia.ca/~serguei/psql-ru.po > http://www.cs.concordia.ca/~serguei/pg_dump-ru.po And the very last one! http://www.cs.concordia.ca/~serguei/pg_resetxlog-ru.po Muchas gracias! -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-ru-general] [HACKERS] Final call for translation updates
Serguei A. Mokhov wrote: > > http://www.cs.concordia.ca/~serguei/initdb-ru.po > > http://www.cs.concordia.ca/~serguei/pg_config-ru.po > > http://www.cs.concordia.ca/~serguei/pg_ctl-ru.po > > http://www.cs.concordia.ca/~serguei/psql-ru.po > > http://www.cs.concordia.ca/~serguei/pg_dump-ru.po > > And the very last one! > > http://www.cs.concordia.ca/~serguei/pg_resetxlog-ru.po Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] transformExpr() refactor
On Thu, 2004-10-28 at 16:49 +1000, Neil Conway wrote:
> This patch refactors transformExpr(): rather than being a monsterous 900
> line function, it breaks it up into numerous sub-functions that are
> invoked by transformExpr() for individual expression types, in the style
> of transformStmt().
I still think this patch is worth applying. Sadly, I will need to
basically rewrite it due to code drift. I'm happy to do that, although
I'd like to resolve whether we want to accept it or not. Tom and Bruce
objected when I posted it originally, although I don't think we reached
a conclusion.
Why I think the patch is a good idea: 900 line functions are almost
universally bad (in fact, I'd be tempted to remove the "almost"). A 900
line function that divides distinct functionality into different
branches of a "switch" statement isn't _that_ evil, but it is still a
large hunk of code for someone to understand as a single, monolithic
unit. Because each branch of the "switch" statement is independent, we
can trivially split each branch off into a function -- each branch does
something distinct, so it ought to be a distinct function. That means
the independence of each branch of the "switch" statement is guaranteed
(the function can't modify a local variable in the calling function, for
example), and it means that the code is conceptually easier to read.
With the present layout,
It does mean that you'll need to jump to the function definition if you
want to see what a particular branch of the "switch" statement does. But
(a) use tags, it's not tough (b) this is a _good_ thing. If I want to
understand what the parent function does (transformExpr(), the one with
the "switch"), I don't want to have to grok through a 700 line "switch"
statement. If each branch of the switch just invokes a function, the
intent of transformExpr() is perfectly clear.
For refresh everyone's memory, I've attached the original version of the
patch. It won't apply cleanly to current sources, but it should apply to
HEAD as of approximately Oct. 28, 2004.
-Neil
Index: src/backend/parser/parse_expr.c
===
RCS file: /var/lib/cvs/pgsql/src/backend/parser/parse_expr.c,v
retrieving revision 1.176
diff -c -r1.176 parse_expr.c
*** src/backend/parser/parse_expr.c 29 Aug 2004 05:06:44 - 1.176
--- src/backend/parser/parse_expr.c 28 Oct 2004 06:46:54 -
***
*** 37,45
--- 37,62
bool Transform_null_equals = false;
+ static Node *transformParamRef(ParseState *pstate, ParamRef *pref);
+ static Node *transformAExprOp(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprAnd(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprOr(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprNot(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprOpAny(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprOpAll(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprDistinct(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprNullIf(ParseState *pstate, A_Expr *a);
+ static Node *transformAExprOf(ParseState *pstate, A_Expr *a);
+ static Node *transformFuncCall(ParseState *pstate, FuncCall *fn);
+ static Node *transformCaseExpr(ParseState *pstate, CaseExpr *c);
+ static Node *transformSubLink(ParseState *pstate, SubLink *sublink);
+ static Node *transformArrayExpr(ParseState *pstate, ArrayExpr *a);
+ static Node *transformRowExpr(ParseState *pstate, RowExpr *r);
+ static Node *transformCoalesceExpr(ParseState *pstate, CoalesceExpr *c);
static Node *transformColumnRef(ParseState *pstate, ColumnRef *cref);
static Node *transformWholeRowRef(ParseState *pstate, char *schemaname,
char *relname);
+ static Node *transformBooleanTest(ParseState *pstate, BooleanTest *b);
static Node *transformIndirection(ParseState *pstate, Node *basenode,
List *indirection);
static Node *typecast_expression(ParseState *pstate, Node *expr,
***
*** 90,154
switch (nodeTag(expr))
{
case T_ColumnRef:
! {
! result = transformColumnRef(pstate, (ColumnRef *) expr);
! break;
! }
case T_ParamRef:
! {
! ParamRef *pref = (ParamRef *) expr;
! int paramno = pref->number;
! ParseState *toppstate;
! Param *param;
!
! /*
! * Find topmost ParseState, which is where paramtype info
! * lives.
! */
! toppstate = pstate;
! while (toppstate->parentParseState != NULL)
! toppstate = toppstate->parentParseState;
!
! /* Check parameter number is in range */
! if (paramno <= 0) /* probably can't happen? */
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_PARAMETER),
! errmsg("there is no parameter $%d", paramno)));
! if (paramno > toppstate->p_numparams)
! {
! if (!toppstate->p_variableparams)
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_PARAMETER),
! errmsg("there is no parameter $%d"
Re: [PATCHES] rtree: improve performance, tuple killing
Barring any objections, I intend to apply this patch tomorrow. The
patch, as well as the original -patches email, are included below.
-Neil
On Wed, 2004-11-24 at 11:15 +1100, Neil Conway wrote:
> This patch makes some improvements to the rtree index implementation:
>
> (1) Keep a pin on the scan's current buffer and mark buffer. This avoids
> the need to do a ReadBuffer() for each tuple produced by the scan.
>
> (2) Convert a ReleaseBuffer() ; ReadBuffer() pair into
> ReleaseAndReadBuffer(). Surely not a huge win, but it saves a lock
> acquire/release...
>
> (3) Remove a bunch of duplicated code in rtget.c; make rtnext() handle
> both the "initial result" and "subsequent result" cases.
>
> (4) Add support for index tuple killing
>
> (5) Remove rtscancache(): it is dead code, for the same reason that
> gistscancache() is dead code (an index scan ought not be invoked with
> NoMovementScanDirection).
>
> The end result is about a 10% improvement in index scan performance,
> according to contrib/rtree_gist/bench.
>
> These changes (with the exception of #2) are analogous to changes I've
> already made for GiST (it's clear that GiST was started as a fork of
> rtree). I'm not hugely interested in further improvements to rtree; I
> just did this stuff because it is low-hanging fruit and I've already
> made the same changes for GiST.
#
# patch "src/backend/access/rtree/rtget.c"
# from [3db9a1c0391d9e319ac8455167f23215e00bf832]
#to [ebfe121a3bcd3e2a15da91e14a84b69c87afac67]
#
# patch "src/backend/access/rtree/rtree.c"
# from [274583f574bc483a709b46912a567c58c6abb98c]
#to [8df26216af5a60db10afd38e3f1dc5c6355ec79c]
#
# patch "src/backend/access/rtree/rtscan.c"
# from [9ace8f57b28397296b386955fdf3b7b712178a9a]
#to [92b177352fd28ffab208ac9abf502cb4c81d2740]
#
# patch "src/include/access/rtree.h"
# from [d3b048ba826b36bc766de324779c0b5bbb143b42]
#to [e4947131a99641d8f43c4b7b770485c8c1043094]
#
--- src/backend/access/rtree/rtget.c
+++ src/backend/access/rtree/rtget.c
@@ -19,10 +19,8 @@
#include "access/relscan.h"
#include "access/rtree.h"
-static OffsetNumber findnext(IndexScanDesc s, Page p, OffsetNumber n,
+static OffsetNumber findnext(IndexScanDesc s, OffsetNumber n,
ScanDirection dir);
-static bool rtscancache(IndexScanDesc s, ScanDirection dir);
-static bool rtfirst(IndexScanDesc s, ScanDirection dir);
static bool rtnext(IndexScanDesc s, ScanDirection dir);
@@ -31,138 +29,106 @@
{
IndexScanDesc s = (IndexScanDesc) PG_GETARG_POINTER(0);
ScanDirection dir = (ScanDirection) PG_GETARG_INT32(1);
- bool res;
-
- /* if we have it cached in the scan desc, just return the value */
- if (rtscancache(s, dir))
- PG_RETURN_BOOL(true);
-
- /* not cached, so we'll have to do some work */
- if (ItemPointerIsValid(&(s->currentItemData)))
- res = rtnext(s, dir);
- else
- res = rtfirst(s, dir);
- PG_RETURN_BOOL(res);
-}
-
-static bool
-rtfirst(IndexScanDesc s, ScanDirection dir)
-{
- Buffer b;
- Page p;
- OffsetNumber n;
- OffsetNumber maxoff;
- RTreePageOpaque po;
+ Page page;
+ OffsetNumber offnum;
RTreeScanOpaque so;
- RTSTACK*stk;
- BlockNumber blk;
- IndexTuple it;
- b = ReadBuffer(s->indexRelation, P_ROOT);
- p = BufferGetPage(b);
- po = (RTreePageOpaque) PageGetSpecialPointer(p);
so = (RTreeScanOpaque) s->opaque;
- for (;;)
+ /*
+ * If we've already produced a tuple and the executor has informed
+ * us that it should be marked "killed", do so know.
+ */
+ if (s->kill_prior_tuple && ItemPointerIsValid(&(s->currentItemData)))
{
- maxoff = PageGetMaxOffsetNumber(p);
- if (ScanDirectionIsBackward(dir))
- n = findnext(s, p, maxoff, dir);
- else
- n = findnext(s, p, FirstOffsetNumber, dir);
+ offnum = ItemPointerGetOffsetNumber(&(s->currentItemData));
+ page = BufferGetPage(so->curbuf);
+ PageGetItemId(page, offnum)->lp_flags |= LP_DELETE;
+ SetBufferCommitInfoNeedsSave(so->curbuf);
+ }
- while (n < FirstOffsetNumber || n > maxoff)
- {
- ReleaseBuffer(b);
- if (so->s_stack == NULL)
-return false;
+ /*
+ * Get the next tuple that matches the search key; if asked to
+ * skip killed tuples, find the first non-killed tuple that
+ * matches. Return as soon as we've run out of matches or we've
+ * found an acceptable match.
+ */
+ for (;;)
+ {
+ bool res = rtnext(s, dir);
- stk = so->s_stack;
- b = ReadBuffer(s->indexRelation, stk->rts_blk);
- p = BufferGetPage(b);
- po = (RTreePageOpaque) PageGetSpecialPointer(p);
- maxoff = PageGetMaxOffsetNumber(p);
-
- if (ScanDirectionIsBackward(dir))
-n = OffsetNumberPrev(stk->rts_child);
- else
-n = OffsetNumberNext(stk->rts_child);
- so->s_stack = stk->rts_parent;
- pfree(stk);
-
- n = findnext(s, p, n, dir);
- }
- if (po->flags & F_LEAF)
+ if (res == true && s->ignore_killed_tuples)
{
- ItemPointerSet(&(s->currentItemData), BufferGetBlockNumber(b), n);
-
- it = (IndexTuple) PageGetItem(p, PageGetItemId(p, n));
-
- s->xs_ctup.t_self = it->t_tid;
-
- Re
Re: [PATCHES] transformExpr() refactor
Neil Conway <[EMAIL PROTECTED]> writes: > Why I think the patch is a good idea: 900 line functions are almost > universally bad (in fact, I'd be tempted to remove the "almost"). [ shrug... ] 900 line functions that consist of absolutely independent case arms are not any harder to read than the alternative. I won't stand in the way of you doing this, but I think you could find more profitable uses for your time. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] WIP: pl/pgsql cleanup
Neil Conway <[EMAIL PROTECTED]> writes: > This patch makes a number of cleanups to PL/PgSQL: > - replaced all uses of malloc/strdup with palloc/pstrdup. > ... > (This was surprisingly easy, btw, so I am suspect that I've missed > something fundamental -- hence the patch is marked WIP. Guidance would > be welcome.) I think that the existing parsing code feels free to palloc junk data that needn't be kept around as part of the finished function definition. It might be better to keep CurrentMemoryContext pointing at a temp context, and translate malloc() to MemoryContextAlloc(function_context) rather than just palloc(). (Of course you could hide this in a macro, maybe falloc()?) Other than that consideration, I never thought it would be complex to do this, just tedious. As long as you're sure you caught everyplace that needs to change ... I don't have time to study the diff now, but your summary sounds good on the other points. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
