Re: [PATCHES] dbsize patch

2005-02-27 Thread Bruce Momjian

Patch applied.  Thanks.

I renamed aggregate_relation_size() to total_relation_size().  To me
'aggregate' was too closely associated with 'aggregates'.  If you have
improved wording please let me know.

---


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 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] UTF8 or Unicode

2005-02-27 Thread lsunley
The routines that do the conversion could have alternate names specified
in the conversion_create.sql. There is not reason that I can see why you
cannot have two function names pointing to the same routine.

like

CREATE OR REPLACE FUNCTION ascii_to_mic (INTEGER, INTEGER, CSTRING,
CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic'
LANGUAGE 'c' STRICT;

and 

CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING,
CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic'
LANGUAGE 'c' STRICT;

I just tried with those two and it works OK

That way you do not break compatibility with existing SQL scripts and/or 
programs using the existing function names.

Lorne


In [EMAIL PROTECTED], on 02/26/05 
   at 03:50 PM, Bruce Momjian pgman@candle.pha.pa.us said:


Peter Eisentraut wrote:
 Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
  so I see what he is saying.  We are not consistent in favoring the
  official names vs. the common names.
 
  I will work on a patch that people can review and test.
 
 I think this is what we should do:
 
 UNICODE = UTF8
 ALT = WIN866
 WIN = WIN1251
 TCVN = WIN1258
 
 That should clear it up.

OK, here is a patch that makes those changes.

The only uncertainty I have is with the the use of the TCVN conversion
routine names, e.g.:

   SELECT CONVERT('foo' USING tcvn_to_utf_8);

I assume this is the same as:

   SELECT CONVERT('foo', 'WIN1258', 'UTF8');
and
   SELECT CONVERT('foo', 'TCVN', 'UTF8');   -- alias usage

So, why would people use the routine name?  Both forms are documented. 
The first one with USING does not accept aliases, while the others do.

I think this should be renamed to win1258_to_utf_8.  However, this would
be an incompatibility.  We should mention it in the release notes.

Other than that the other conversion files were already named fine, e.g.
ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8.  I am
unsure how to handle these.



-- 
---
[EMAIL PROTECTED]
---


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] int4 - bool casts

2005-02-27 Thread Neil Conway
I've applied a modified version of this patch from seanc:
http://candle.pha.pa.us/mhonarc/patches2/msg00029.html
(Sorry, I've lost the original thread.) The patch as I applied it is 
attached. Catalog version bumped.

-Neil
Index: src/backend/utils/adt/int.c
===
RCS file: /Users/neilc/local/cvs/pgsql/src/backend/utils/adt/int.c,v
retrieving revision 1.64
diff -c -r1.64 int.c
*** src/backend/utils/adt/int.c	31 Dec 2004 22:01:22 -	1.64
--- src/backend/utils/adt/int.c	27 Feb 2005 08:06:40 -
***
*** 361,366 
--- 361,385 
  	return result;
  }
  
+ /* Cast int4 - bool */
+ Datum
+ int4_bool(PG_FUNCTION_ARGS)
+ {
+ 	if (PG_GETARG_INT32(0) == 0)
+ 		PG_RETURN_BOOL(false);
+ 	else
+ 		PG_RETURN_BOOL(true);
+ }
+ 
+ /* Cast bool - int4 */
+ Datum
+ bool_int4(PG_FUNCTION_ARGS)
+ {
+ 	if (PG_GETARG_BOOL(0) == false)
+ 		PG_RETURN_INT32(0);
+ 	else
+ 		PG_RETURN_INT32(1);
+ }
  
  /*
   *		
Index: src/include/catalog/catversion.h
===
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.255
diff -c -r1.255 catversion.h
*** src/include/catalog/catversion.h	26 Feb 2005 18:43:34 -	1.255
--- src/include/catalog/catversion.h	27 Feb 2005 08:29:35 -
***
*** 53,58 
   */
  
  /*			mmddN */
! #define CATALOG_VERSION_NO	200502261
  
  #endif
--- 53,58 
   */
  
  /*			mmddN */
! #define CATALOG_VERSION_NO	200502271
  
  #endif
Index: src/include/catalog/pg_cast.h
===
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/pg_cast.h,v
retrieving revision 1.17
diff -c -r1.17 pg_cast.h
*** src/include/catalog/pg_cast.h	1 Jan 2005 05:43:09 -	1.17
--- src/include/catalog/pg_cast.h	27 Feb 2005 08:02:47 -
***
*** 101,106 
--- 101,110 
  DATA(insert ( 1700	700 1745 i ));
  DATA(insert ( 1700	701 1746 i ));
  
+ /* Allow explicit coercions between int4 and bool */
+ DATA(insert (	23	16  2557 e ));
+ DATA(insert (	16	23  2558 e ));
+ 
  /*
   * OID category: allow implicit conversion from any integral type (including
   * int8, to support OID literals  2G) to OID, as well as assignment coercion
Index: src/include/catalog/pg_proc.h
===
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.350
diff -c -r1.350 pg_proc.h
*** src/include/catalog/pg_proc.h	26 Feb 2005 18:43:34 -	1.350
--- src/include/catalog/pg_proc.h	27 Feb 2005 07:59:05 -
***
*** 3604,3609 
--- 3604,3614 
  DATA(insert OID = 2556 ( pg_tablespace_databases	PGNSP PGUID 12 f f t t s 1 26 26 _null_ pg_tablespace_databases - _null_));
  DESCR(returns database oids in a tablespace);
  
+ DATA(insert OID = 2557 ( bool   PGNSP PGUID 12 f f t f i 1  16 23 _null_	int4_bool - _null_ ));
+ DESCR(convert int4 to boolean);
+ DATA(insert OID = 2558 ( int4   PGNSP PGUID 12 f f t f i 1  23 16 _null_	bool_int4 - _null_ ));
+ DESCR(convert boolean to int4);
+ 
  
  /*
   * Symbolic values for provolatile column: these indicate whether the result
Index: src/include/utils/builtins.h
===
RCS file: /Users/neilc/local/cvs/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.252
diff -c -r1.252 builtins.h
*** src/include/utils/builtins.h	31 Dec 2004 22:03:45 -	1.252
--- src/include/utils/builtins.h	27 Feb 2005 08:07:13 -
***
*** 111,116 
--- 111,118 
  extern Datum i4toi2(PG_FUNCTION_ARGS);
  extern Datum int2_text(PG_FUNCTION_ARGS);
  extern Datum text_int2(PG_FUNCTION_ARGS);
+ extern Datum int4_bool(PG_FUNCTION_ARGS);
+ extern Datum bool_int4(PG_FUNCTION_ARGS);
  extern Datum int4_text(PG_FUNCTION_ARGS);
  extern Datum text_int4(PG_FUNCTION_ARGS);
  extern Datum int4eq(PG_FUNCTION_ARGS);

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] UTF8 or Unicode

2005-02-27 Thread lsunley
In [EMAIL PROTECTED], on 02/26/05 
   at 11:09 PM, Bruce Momjian pgman@candle.pha.pa.us said:



Here is an updated version that handles all cases.  It does rename the
routine names so the primary encoding name is used for the routine names. 
This will be documented in the release notes if anyone actually uses
those names in their code.

This patch requires renaming of the utf8_and_tcvn directory so it will
not apply cleanly.

I left the routines named utf_8 alone because the code splits encoding
names at breaks, like this iso_8859_7_to_utf_8.  I assume that is OK.


You cannot patch conversion_create.sql

You have to patch the makefile that generates it.

The CONVERSIONS variable has the names etc and the

@set $(CONVERSIONS) etc code generates the conversion_create.sql file

-- 
---
[EMAIL PROTECTED]
---


---(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


[PATCHES] array max() / min()

2005-02-27 Thread Neil Conway
Barring any objections, I'll apply this patch to HEAD tomorrow:
http://candle.pha.pa.us/mhonarc/patches2/msg7.html
(Sorry, lost track of this patch as well... :P)
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] [HACKERS] UTF8 or Unicode

2005-02-27 Thread lsunley
Ignore previous e-mail...

Missed the patch to the makefile

Sorry about that

-- 
---
[EMAIL PROTECTED]
---


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384

2005-02-27 Thread Magnus Hagander
Actually, I'd like it considered for 8.0.X as well. Right now if yuo
change the config file in a way that it won't load, you get no error
message. Which is cearly not very good. I'll certainly accept if you
think it's not safe enough for 8.0.x, but please consider it.

//Magnus


-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
Sent: den 27 februari 2005 02:04
To: Magnus Hagander
Cc: Tom Lane; PostgreSQL-patches; Andreas Pflug
Subject: Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384



Patch applied.  Thanks.

I assume this is not for 8.0.X.

---



Magnus Hagander wrote:
  The proposed test on Redirect_stderr looks pretty fishy 
too; for one
  thing it will almost certainly not be the right thing 
 inside the stderr
  logger subprocess itself.
 
  Could you explain further what the issue is there? 
 
 Inside the logger subprocess, Redirect_stderr is guaranteed 
true (since
 it'll be inherited from the postmaster) and therefore the proposed
 change ensures that anything the logger might want to complain about
 goes to the original stderr, ie, into the bit bucket rather than
 someplace useful.  Perhaps something like
 
 if ((!Redirect_stderr || am_syslogger)  pgwin32_is_service())
 
 would be reasonable.
 
 snip lots of others
 
 Here is an updated patch, that should take care of this. 
Tested that it
 solves the problem reported.
 
 
  There is special code in the send_message_to_server_log 
 function to make
  sure it's written directly to the file.
 
 If the logger is complaining, it's quite possibly because it's 
 unable to
 write to its file.  Now that you mention it, doesn't this 
code go into
 infinite recursion if write_syslogger_file_binary() tries 
to ereport?
 
 
 I haven't looked at this part, it appears a separate (but closely
 related) issue.
 
 Perhaps Andreas can comment on this?
 
 //Magnus

Content-Description: stderr.patch

[ Attachment, skipping... ]

 
 ---(end of 
broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq

-- 
  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 7: don't forget to increase your free space map settings


Re: [PATCHES] A way to let Vacuum warn if FSM settings are low.

2005-02-27 Thread Simon Riggs
On Fri, 2005-02-25 at 16:48 -0800, Ron Mayer wrote:
 Getting closer?

For me, yes. 

I agree with Bruce's comment on the use of the word needed, and I
think your change reads better now.

The not-warnings seem a little wordy for me, but they happen when and
how I would hope for. 

So, for me, it looks like a polish of final wording and commit.

Best Regards, Simon Riggs


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] int4 - bool casts

2005-02-27 Thread Peter Eisentraut
Neil Conway wrote:
  I believe I would have objected to an int/bool cast. I do so now
  anyway.

 On what grounds?

I can think of a couple of reasons:

- Casting back and forth does not preserve information.  (This may be 
true for some other type pairs as well, but in this case it's true in 
almost every instance.)

- It's an arbitary definition that is not obviously supported by 
mathematical or similar principles.

- It opens the door for other silly casts like empty string = false, 
non-empty string = true.

- It's unnecessary because you can express the same thing using other 
expressions that clearly state what they do.

-- 
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


[PATCHES] win32 libpq build broken

2005-02-27 Thread Magnus Hagander
by the change to gettext. Needs a bunch of new includes. Patch follows:


diff -c -r1.13 win32.c
*** win32.c 22 Feb 2005 04:42:20 -  1.13
--- win32.c 27 Feb 2005 17:36:06 -
***
*** 19,26 
  
  /* Make stuff compile faster by excluding not used stuff */
  
- #define WIN32_LEAN_AND_MEAN
- #define WIN32_EXTRA_LEAN
  #define VC_EXTRALEAN
  #ifndef __MINGW32__
  #define NOGDI
--- 19,24 
***
*** 31,36 
--- 29,37 
  #include winsock.h
  #include stdio.h
  #include win32.h
+ #include postgres_fe.h
+ #include libpq-fe.h
+ #include libpq-int.h
  
  static struct WSErrorEntry
  {

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster