Re: [PATCHES] Clarify use of NOW() in pl/pgsql docs
On Feb 10, 2005, at 14:00, Neil Conway wrote: On Thu, 2005-01-27 at 02:28 -0800, David Fetter wrote: This one from Ben Calvert. It uses the (imho clearer) NOW() rather than 'NOW' in a PL/PgSQL function example. Applied, thanks. I realize it's a bit late, but it might not be a bad idea to use CURRENT_TIMESTAMP rather than NOW(), as it's per SQL spec. Michael Glaesemann grzm myrealbox com ---(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] WIP: pl/pgsql cleanup
On Wed, 2005-02-09 at 23:57 -0500, Tom Lane wrote: > That seems like a step backwards from the current behavior [...] Hmm, fair enough. Is this better? create function bad_sql1() returns int as $$ declare a int; begin a := 5; Johnny Yuma; a := 10; return a; end$$ language 'plpgsql'; ERROR: syntax error at or near "Johnny" at character 1 QUERY: Johnny Yuma CONTEXT: SQL statement embedded in PL/PgSQL function "bad_sql1" near line 4 LINE 1: Johnny Yuma ^ -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [Fwd: Re: [DOCS] Instructions for FreeBSD ipc config
Applied, thanks. On Wed, 2005-02-02 at 17:33 +1300, Mark Kirkwood wrote: > As discussed on -docs. > (Not really sure if I need to explicitly forward here) Yeah, forwarding (or CC'ing) to -patches is helpful. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Clarify use of NOW() in pl/pgsql docs
On Thu, 2005-01-27 at 02:28 -0800, David Fetter wrote: > This one from Ben Calvert. It uses the (imho clearer) NOW() rather > than 'NOW' in a PL/PgSQL function example. Applied, thanks. -Neil ---(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: [PATCHES] WIP: pl/pgsql cleanup
Neil Conway <[EMAIL PROTECTED]> writes: > create function bad_sql1() returns int as $$ > declare a int; > begin > a := 5; > Johnny Yuma; > a := 10; > return a; > end$$ language 'plpgsql'; > ERROR: syntax error at or near "Johnny" > CONTEXT: SQL statement embedded in PL/PgSQL function "bad_sql1" near > line 4 That seems like a step backwards from the current behavior: regression=# create function bad_sql1() returns int as $$ regression$# declare a int; regression$# begin regression$# a := 5; regression$# Johnny Yuma; regression$# a := 10; regression$# return a; regression$# end$$ language 'plpgsql'; CREATE FUNCTION regression=# select bad_sql1(); ERROR: syntax error at or near "Johnny" at character 1 QUERY: Johnny Yuma CONTEXT: PL/pgSQL function "bad_sql1" line 4 at SQL statement LINE 1: Johnny Yuma ^ regression=# While the difference in information content may not seem great, it is a big deal when you are talking about a small syntax error in a large SQL command spanning many lines. 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
Another version of the patch is attached. Changes: - clean up grammar so that read_sql_construct() is always called to read a well-formed SQL expression. That way we can check for errors in embedded SQL by just adding a single function call to read_sql_construct(), rather than adding calls at most of its call sites. - changed location of array overflow checks per Tom - mostly fixed error message formatting for syntax errors in PL/PgSQL. I found this part of the ereport() framework rather confusing. The patch currently emits errors like: create function bad_sql1() returns int as $$ declare a int; begin a := 5; Johnny Yuma; a := 10; return a; end$$ language 'plpgsql'; ERROR: syntax error at or near "Johnny" CONTEXT: SQL statement embedded in PL/PgSQL function "bad_sql1" near line 4 Any suggestions for improvement would be welcome. Barring any objections, I'd like to apply this patch to HEAD tomorrow. -Neil plpgsql_cleanup-26.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] dbsize patch
Neil Conway wrote: > On Wed, 2005-02-09 at 18:35 -0500, Bruce Momjian wrote: > > It is still in my mailbox for review. Sorry. > > Yeah, my apologies as well, I've been busy with other things. Bruce, if > you'd like to review & apply this you are welcome to. Otherwise let me > know and I'll take a look. Who ever gets to it first can deal with it. -- 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] dbsize patch
On Wed, 2005-02-09 at 18:35 -0500, Bruce Momjian wrote: > It is still in my mailbox for review. Sorry. Yeah, my apologies as well, I've been busy with other things. Bruce, if you'd like to review & apply this you are welcome to. Otherwise let me know and I'll take a look. -Neil ---(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] dbsize patch
It is still in my mailbox for review. Sorry.
---
Ed L. wrote:
> On Thursday February 3 2005 9:23, Ed L. wrote:
> > Neil, do you have a verdict on this patch?
> >
> > On Friday January 28 2005 10:30, Ed L. wrote:
> > > If the C code for the prior dbsize patch is not acceptable
> > > for whatever reason, here's a SQL-based patch to replace it.
>
> I submitted a dbsize patch on Jan 25, revised it twice per
> concerns raised by Michael Paesold and Neil Conway ("indexes"
> instead of "indices") and Andreas Pflug and Tom Lane (implement
> in SQL instead of C) and resubmitted Jan 28. I've not received
> any further communication regarding the patch. Please advise if
> there are concerns. I've attached the patch again, slightly
> cleaned up, in case it has fallen through the cracks.
>
> Ed
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
--
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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] memory leak in ALTER TABLE
On Wed, 2005-02-09 at 15:56 +1100, Neil Conway wrote: > This patch changes ATRewriteTable() to switch to the per-tuple memory > context before beginning the per-tuple loop. [...] > Barring any objections, I will apply this to HEAD and REL8_0_STABLE > tomorrow. Applied. -Neil ---(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: [PATCHES] dbsize patch
On Thursday February 3 2005 9:23, Ed L. wrote:
> Neil, do you have a verdict on this patch?
>
> On Friday January 28 2005 10:30, Ed L. wrote:
> > If the C code for the prior dbsize patch is not acceptable
> > for whatever reason, here's a SQL-based patch to replace it.
I submitted a dbsize patch on Jan 25, revised it twice per
concerns raised by Michael Paesold and Neil Conway ("indexes"
instead of "indices") and Andreas Pflug and Tom Lane (implement
in SQL instead of C) and resubmitted Jan 28. I've not received
any further communication regarding the patch. Please advise if
there are concerns. I've attached the patch again, slightly
cleaned up, in case it has fallen through the cracks.
Ed
Index: README.dbsize
===
RCS file: /projects/cvsroot/pgsql/contrib/dbsize/README.dbsize,v
retrieving revision 1.4
diff -C1 -r1.4 README.dbsize
*** README.dbsize 28 Sep 2004 19:35:43 - 1.4
--- README.dbsize 6 Feb 2005 15:06:19 -
***
*** 1,3
! This module contains several functions that report the size of a given
! database object:
--- 1,3
! This module contains several functions that report the on-disk size of a
! given database object in bytes:
***
*** 5,6
--- 5,8
int8 relation_size(text)
+ int8 indexes_size(text)
+ int8 aggregate_relation_size(text)
***
*** 12,14
! The first two functions:
--- 14,20
! setof record relation_size_components(text)
!
! The first four functions take the name of the object (possibly
! schema-qualified for the latter three) and returns the size of the
! on-disk files in bytes.
***
*** 16,20
SELECT relation_size('pg_class');
! take the name of the object (possibly schema-qualified, for relation_size),
! while these functions take object OIDs:
--- 22,27
SELECT relation_size('pg_class');
+ SELECT indexes_size('pg_class');
+ SELECT aggregate_relation_size('pg_class');
! These functions take object OIDs:
***
*** 24,49
Please note that relation_size and pg_relation_size report only the size of
! the selected relation itself; any subsidiary indexes or toast tables are not
! counted. To obtain the total size of a table including all helper files
! you'd have to do something like:
!
! SELECT *,
! pg_size_pretty(tablesize+indexsize+toastsize+toastindexsize) AS totalsize
! FROM
! (SELECT pg_relation_size(cl.oid) AS tablesize,
! COALESCE((SELECT SUM(pg_relation_size(indexrelid))::bigint
! FROM pg_index WHERE cl.oid=indrelid), 0) AS indexsize,
! CASE WHEN reltoastrelid=0 THEN 0
! ELSE pg_relation_size(reltoastrelid)
! END AS toastsize,
! CASE WHEN reltoastrelid=0 THEN 0
! ELSE pg_relation_size((SELECT reltoastidxid FROM pg_class ct
! WHERE ct.oid = cl.reltoastrelid))
! END AS toastindexsize
! FROM pg_class cl
! WHERE relname = 'foo') ss;
!
! This sample query utilizes the helper function pg_size_pretty(int8),
! which formats the number of bytes into a convenient string using KB, MB,
! GB. It is also contained in this module.
--- 31,113
+ The indexes_size() function returns the total size of the indices for a
+ relation, including any toasted indices.
+
+ The aggregate_relation_size() function returns the total size of the relation,
+ all its indices, and any toasted data.
+
Please note that relation_size and pg_relation_size report only the size of
! the selected relation itself; any related indexes or toast tables are not
! counted. To obtain the total size of a table including all indices and
! toasted data, use aggregate_relation_size().
!
! The last function, relation_size_components(), returns a set of rows
! showing the sizes of the component relations constituting the input
! relation.
!
! Examples
!
!
! I've loaded the following table with a little less than 3 MB of data for
! illustration:
!
! create table fat ( id serial, data varchar );
! create index fat_uidx on fat (id);
! create index fat_idx on fat (data);
!
! You can retrieve a rowset containing constituent sizes as follows:
!
! # SELECT relation_size_components('fat');
! relation_size_components
!
! (2088960,65536,2891776,fat,r,59383,59383)
! (32768,704512,737280,pg_toast_59383,t,59386,59386)
! (0,32768,32768,pg_toast_59383_index,i,59388,59388)
! (0,2039808,2039808,fat_idx,i,59389,59389)
! (0,49152,49152,fat_uidx,i,59911,59911)
! (5 rows)
!
! To see a more readable output of the rowset:
!
! SELECT *
! FROM relation_size_components('fat') AS (idxsize BIGINT,
! datasize BIGINT,
! totalsize BIGINT,
!
[PATCHES] Repleacement for src/port/snprintf.c
Hello all,
I would like to submit my changes to src/port/snprintf.c to
enable %n$ format placeholder replacement in snprintf() and
vsnprintf(). Additionally I implemented a trivial printf().
I also attach a diff for configure.in to include snprintf.o
in pgport but I am sure it is not the right thing to do.
Could someone give a hint on where I need to place such a
definition.
Please review my patch. as Tom Lane pointed out there
are 150 messages in the following files that do not print
properly:
src/backend/po/pt_BR.po
src/backend/po/de.po
src/backend/po/es.po
src/backend/po/zh_CN.po
src/backend/po/tr.po
src/bin/pg_dump/po/zh_CN.po
src/bin/pg_dump/po/tr.po
src/bin/psql/po/zh_CN.po
src/bin/psql/po/zh_TW.po
src/bin/psql/po/tr.po
src/bin/scripts/po/zh_CN.po
we need to fix snprintf.c before next release
Best regards,
Nicolai Tufar
*** ./src/port/snprintf.c.orig 2005-01-20 01:27:22.0 +0200
--- ./src/port/snprintf.c 2005-01-24 03:09:31.0 +0200
***
*** 57,62
--- 57,66
typedef unsigned long ulong_long;
#endif
+ #ifndef NL_ARGMAX
+ #define NL_ARGMAX 4096
+ #endif
+
/*
**SNPRINTF, VSNPRINT -- counted versions of printf
**
***
*** 85,93
--- 89,115
int snprintf(char *str, size_t count, const char *fmt,...);
int vsnprintf(char *str, size_t count, const char *fmt,
va_list args);
+ int printf(const char *format, ...);
static void dopr(char *buffer, const char *format, va_list args);
int
+ printf(const char *fmt,...)
+ {
+ int len;
+ va_list args;
+ static char*buffer[4096];
+ char* p;
+
+ va_start(args, fmt);
+ len = vsnprintf((char*)buffer, (size_t)4096, fmt, args);
+ va_end(args);
+ p = (char*)buffer;
+ for(;*p;p++)
+ putchar(*p);
+ return len;
+ }
+
+ int
snprintf(char *str, size_t count, const char *fmt,...)
{
int len;
***
*** 124,129
--- 146,155
static char *output;
+ #define FMTSTR 1
+ #define FMTNUM 2
+ #define FMTFLOAT3
+ #define FMTCHAR 4
static void
dopr(char *buffer, const char *format, va_list args)
***
*** 139,145
--- 165,200
int ljust;
int len;
int zpad;
+ int i;
+ const char* format_save;
+ const char* fmtbegin;
+ int fmtpos = 1;
+ int realpos = 0;
+ int position;
+ static struct{
+ const char* fmtbegin;
+ const char* fmtend;
+ union{
+ void* value;
+ long_long numvalue;
+ double fvalue;
+ int charvalue;
+ };
+ int ljust;
+ int len;
+ int zpad;
+ int maxwidth;
+ int base;
+ int dosign;
+ chartype;
+ int precision;
+ int pointflag;
+ charfunc;
+ int realpos;
+ }fmtpar[NL_ARGMAX+1], *fmtparptr[NL_ARGMAX+1];
+
+ format_save = format;
output = buffer;
while ((ch = *format++))
{
***
*** 148,161
case '%':
ljust = len = zpad = maxwidth = 0;
longflag = longlongflag = pointflag = 0;
nextch:
ch = *format++;
switch (ch)
{
case 0:
! dostr("**end of format**", 0);
! *output = '\0';
! return;
case '-':
ljust = 1;
goto nextch;
--- 203,217
case '%':
ljust = len = zpad = maxwidth = 0;
longflag = longlongflag = pointflag = 0;
+ fmtbegin = format - 1;
+ realpos = 0;
+ position = 0;
nextch:
ch = *format++;
switch (ch)
{
case 0:
! goto performpr;
