[PATCHES] Romanian translation for 8.0: new file (pgscripts)
Please update whatever nls.mk is necessary. Thank you, Alin pgscripts-ro.po.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] dllist.c 0 - NULL
This has been saved for the 8.1 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --- Alvaro Herrera wrote: Hackers, This patches corrects the use of 0 as NULL in dllist.c, as reported by sparse. There are still other places to be corrected. Althought fairly trivial, it's not meant to be applied just now ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El que vive para el futuro es un iluso, y el que vive para el pasado, un imb?cil (Luis Adler, Los tripulantes de la noche) [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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] Increased error verbosity when querying row-returning
Brendan Jurd [EMAIL PROTECTED] writes: Thanks Alvaro, changes made and new patch attached. I submitted this patch about 5 days ago and I haven't heard anything since. I don't wish to be rude, but I'm not familiar with the pgsql-patches etiquette yet, and I noticed most submissions and questions are getting responses very quickly. This is in the category of stuff that has to wait for 8.1, so nothing will be done with it until after we fork the CVS tree (which should happen any day now). If we weren't busy with getting 8.0 out the door, there'd probably be more response, but right now small patches are just going into the to-look-at-later folder... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Increased error verbosity when querying row-returning
Tom Lane wrote: Brendan Jurd [EMAIL PROTECTED] writes: Thanks Alvaro, changes made and new patch attached. I submitted this patch about 5 days ago and I haven't heard anything since. I don't wish to be rude, but I'm not familiar with the pgsql-patches etiquette yet, and I noticed most submissions and questions are getting responses very quickly. This is in the category of stuff that has to wait for 8.1, so nothing will be done with it until after we fork the CVS tree (which should happen any day now). If we weren't busy with getting 8.0 out the door, there'd probably be more response, but right now small patches are just going into the to-look-at-later folder... regards, tom lane That's cool, I've got nothing against it being in the to-look-at-later folder. Just glad it didn't end up in /dev/null by mistake =) Thanks for the clarification. BJ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Increased error verbosity when querying row-returning
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Brendan Jurd wrote:
Alvaro Herrera wrote:
On Wed, Jan 12, 2005 at 09:23:26AM +1100, Brendan Jurd wrote:
This patch to src/backend/executor/nodeFunctionscan.c is intended to
make life a little easier for people using row-returning functions, by
increasing the level of detail in the error messages thrown when
tupledesc_match fails.
You should get rid of the returns, because ereport(ERROR) will never
return control to the function and they are thus dead code. And make
the function return void rather than bool.
Also follow the style: use if (foo) rather than if( foo ). And
message style stipulates that the errdetail() message should start with
a capital (upper case?) letter.
Thanks Alvaro, changes made and new patch attached.
Index: src/backend/executor/nodeFunctionscan.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/executor/nodeFunctionscan.c,v
retrieving revision 1.29
diff -c -r1.29 nodeFunctionscan.c
*** src/backend/executor/nodeFunctionscan.c 31 Dec 2004 21:59:45 -
1.29
--- src/backend/executor/nodeFunctionscan.c 12 Jan 2005 06:36:53 -
***
*** 36,42
static TupleTableSlot *FunctionNext(FunctionScanState *node);
! static bool tupledesc_match(TupleDesc dst_tupdesc, TupleDesc src_tupdesc);
/*
* Scan Support
--- 36,42
static TupleTableSlot *FunctionNext(FunctionScanState *node);
! static void tupledesc_match(TupleDesc dst_tupdesc, TupleDesc src_tupdesc);
/*
* Scan Support
***
*** 87,96
* need to do this for functions returning RECORD, but might as
* well do it always.
*/
! if (funcTupdesc !tupledesc_match(node-tupdesc, funcTupdesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg(query-specified return row and
actual function return row do not match)));
}
/*
--- 87,94
* need to do this for functions returning RECORD, but might as
* well do it always.
*/
! if (funcTupdesc)
! tupledesc_match(node-tupdesc, funcTupdesc);
}
/*
***
*** 357,369
* destination type, so long as the physical storage matches. This is
* helpful in some cases involving out-of-date cached plans.
*/
! static bool
tupledesc_match(TupleDesc dst_tupdesc, TupleDesc src_tupdesc)
{
int i;
if (dst_tupdesc-natts != src_tupdesc-natts)
! return false;
for (i = 0; i dst_tupdesc-natts; i++)
{
--- 355,370
* destination type, so long as the physical storage matches. This is
* helpful in some cases involving out-of-date cached plans.
*/
! static void
tupledesc_match(TupleDesc dst_tupdesc, TupleDesc src_tupdesc)
{
int i;
if (dst_tupdesc-natts != src_tupdesc-natts)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg(function return row and query-specified return
row do not match),
! errdetail(Function-returned row contains %d
attributes, but query expects %d., src_tupdesc-natts, dst_tupdesc-natts)));
for (i = 0; i dst_tupdesc-natts; i++)
{
***
*** 373,382
if (dattr-atttypid == sattr-atttypid)
continue; /* no worries */
if (!dattr-attisdropped)
! return false;
if (dattr-attlen != sattr-attlen ||
dattr-attalign != sattr-attalign)
! return false;
}
return true;
--- 374,393
if (dattr-atttypid == sattr-atttypid)
continue; /* no worries */
if (!dattr-attisdropped)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg(function return row and
query-specified return row do not match),
! errdetail(Function returned type %s at
ordinal position %d, but query expects %s.,
! format_type_be(sattr-atttypid),
! i+1,
!
Re: [PATCHES] Translation updates: pt_BR
Euler Taveira de Oliveira wrote: This is another translation update for pt_BR. http://br.geocities.com/eulerto/pg/nls_pt-br.tgz Installed. Please do not cross-post. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Latest Turkish translation updates
Devrim GUNDUZ wrote: These are the latest updates: Installed. BTW... Peter, we see some errors on postgres-tr.po file, on nlsstatus page (http://developer.postgresql.org/~petere/nlsstatus/po-current/postgre s-tr.po.err) po/postgres-tr.po:9383: number of format specifiers in msgid and msgstr does not match 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. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Translation updates: pt_BR
Peter Eisentraut wrote: Euler Taveira de Oliveira wrote: This is another translation update for pt_BR. http://br.geocities.com/eulerto/pg/nls_pt-br.tgz Installed. Please do not cross-post. Sorry, you didn't actually cross-post. Ignore that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] PL/Perl doc patch
Folks,
Please find enclosed a patch to the pl/perl documents that correctly
tells what arguments go to pl/perl triggers.
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.35
diff -c -r2.35 plperl.sgml
*** doc/src/sgml/plperl.sgml30 Dec 2004 21:45:36 - 2.35
--- doc/src/sgml/plperl.sgml17 Jan 2005 02:46:59 -
***
*** 489,495
/varlistentry
varlistentry
! termliteral$_TD{name}/literal/term
listitem
para
Name of the trigger being called
--- 489,495
/varlistentry
varlistentry
! termliteral$_TD-gt;{name}/literal/term
listitem
para
Name of the trigger being called
***
*** 498,504
/varlistentry
varlistentry
! termliteral$_TD{event}/literal/term
listitem
para
Trigger event: literalINSERT/, literalUPDATE/,
literalDELETE/, or literalUNKNOWN/
--- 498,504
/varlistentry
varlistentry
! termliteral$_TD-gt;{event}/literal/term
listitem
para
Trigger event: literalINSERT/, literalUPDATE/,
literalDELETE/, or literalUNKNOWN/
***
*** 507,513
/varlistentry
varlistentry
! termliteral$_TD{when}/literal/term
listitem
para
When the trigger was called: literalBEFORE/literal,
literalAFTER/literal, or literalUNKNOWN/literal
--- 507,513
/varlistentry
varlistentry
! termliteral$_TD-gt;{when}/literal/term
listitem
para
When the trigger was called: literalBEFORE/literal,
literalAFTER/literal, or literalUNKNOWN/literal
***
*** 516,522
/varlistentry
varlistentry
! termliteral$_TD{level}/literal/term
listitem
para
The trigger level: literalROW/literal,
literalSTATEMENT/literal, or literalUNKNOWN/literal
--- 516,522
/varlistentry
varlistentry
! termliteral$_TD-gt;{level}/literal/term
listitem
para
The trigger level: literalROW/literal,
literalSTATEMENT/literal, or literalUNKNOWN/literal
***
*** 525,531
/varlistentry
varlistentry
! termliteral$_TD{relid}/literal/term
listitem
para
OID of the table on which the trigger fired
--- 525,531
/varlistentry
varlistentry
! termliteral$_TD-gt;{relid}/literal/term
listitem
para
OID of the table on which the trigger fired
***
*** 534,540
/varlistentry
varlistentry
! termliteral$_TD{relname}/literal/term
listitem
para
Name of the table on which the trigger fired
--- 534,540
/varlistentry
varlistentry
! termliteral$_TD-gt;{relname}/literal/term
listitem
para
Name of the table on which the trigger fired
***
*** 543,549
/varlistentry
varlistentry
! termliteral@{$_TD{argv}}/literal/term
listitem
para
Arguments of the trigger function
--- 543,549
/varlistentry
varlistentry
! termliteral@{$_TD-gt;{argv}}/literal/term
listitem
para
Arguments of the trigger function
***
*** 552,558
/varlistentry
varlistentry
! termliteral$_TD{argc}/literal/term
listitem
para
Number of arguments of the trigger function
--- 552,558
/varlistentry
varlistentry
! termliteral$_TD-gt;{argc}/literal/term
listitem
para
Number of arguments of the trigger function
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] Updated translation for Romanian (8.0)
Alin Vaida wrote: Fixed new fuzzy untranslated strings. Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Romanian translation for 8.0: new file (pgscripts)
Alin Vaida wrote: Please update whatever nls.mk is necessary. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PL/Perl doc patch
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developers page. --- David Fetter wrote: Folks, Please find enclosed a patch to the pl/perl documents that correctly tells what arguments go to pl/perl triggers. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] sl translation updates
Aleksander Kmetec wrote: I noticed there were some minor string changes in the past few weeks. Attached are the updated translation files. Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] test: untyped literal in CASE test expr
This trivial patch adds a regression test for CASE expressions that use an untyped literal in the CASE's test expression. This adds test coverage for a bug that was fixed by Tom on Jan. 12 I intend to apply this once 8.0.0 is out the door, barring any objections. -Neil Index: src/test/regress/expected/case.out === RCS file: /var/lib/cvs/pgsql/src/test/regress/expected/case.out,v retrieving revision 1.7 diff -c -r1.7 case.out *** src/test/regress/expected/case.out 1 Dec 2004 19:00:55 - 1.7 --- src/test/regress/expected/case.out 17 Jan 2005 02:51:17 - *** *** 72,77 --- 72,84 6 | 6 (1 row) + -- Test for cases involving untyped literals in test expression + SELECT CASE 'a' WHEN 'a' THEN 1 ELSE 2 END; + case + -- + 1 + (1 row) + -- -- Examples of targets involving tables -- Index: src/test/regress/sql/case.sql === RCS file: /var/lib/cvs/pgsql/src/test/regress/sql/case.sql,v retrieving revision 1.4 diff -c -r1.4 case.sql *** src/test/regress/sql/case.sql 6 Jan 2000 06:41:55 - 1.4 --- src/test/regress/sql/case.sql 17 Jan 2005 02:49:33 - *** *** 58,63 --- 58,66 ELSE 7 END AS Two WHEN with default; + -- Test for cases involving untyped literals in test expression + SELECT CASE 'a' WHEN 'a' THEN 1 ELSE 2 END; + -- -- Examples of targets involving tables -- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] test: untyped literal in CASE test expr
Neil Conway [EMAIL PROTECTED] writes: This trivial patch adds a regression test for CASE expressions that use an untyped literal in the CASE's test expression. This adds test coverage for a bug that was fixed by Tom on Jan. 12 I intend to apply this once 8.0.0 is out the door, barring any objections. I had intended to put in something like that myself, but forgot. Feel free to apply now. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] test: untyped literal in CASE test expr
On Sun, 2005-01-16 at 22:31 -0500, Tom Lane wrote: I had intended to put in something like that myself, but forgot. Feel free to apply now. Applied. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
