Re: [PATCHES] temporal version of generate_series()

2008-04-30 Thread Pavel Stehule
Hello

why you don't use polymorphic types?

like:

create or replace function generate_time_series(anyelement,
anyelement, interval, OUT result anyelement)
returns setof anyelement as $$
begin
  result := $1;
  while (result <= $2) loop
return next;
result := result + $3;
  end loop;
  return;
end;
$$ language plpgsql;

Regards
Pavel Stehule



2008/5/1 H. Harada <[EMAIL PROTECTED]>:
> Here's the sync and updated patch.
> It contains "strict" in catalog as well.
>
> Hitoshi Harada
>
> 2008/4/24 H. Harada <[EMAIL PROTECTED]>:
>> 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>:
>>
>> > H.Harada escribió:
>>  >
>>  >
>>  >  > # This is my first time to send a patch. If I did something wrong, I
>>  >  > appreciate your pointing me out.
>>  >
>>  >  Brace positioning is off w.r.t. our conventions -- please fix that and
>>  >  resubmit.
>>
>>  Here's updated version. Thanks for your advice.
>>
>>  Hitoshi Harada
>>
>>  2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>:
>>
>>
>> > H.Harada escribió:
>>  >
>>  >
>>  >  > # This is my first time to send a patch. If I did something wrong, I
>>  >  > appreciate your pointing me out.
>>  >
>>  >  Brace positioning is off w.r.t. our conventions -- please fix that and
>>  >  resubmit.
>>  >
>>  >  I have added this patch to the May commitfest.
>>  >
>>  >  --
>>  >  Alvaro Herrera
>> http://www.CommandPrompt.com/
>>  >  The PostgreSQL Company - Command Prompt, Inc.
>>  >
>>
>
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches
>
>

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] temporal version of generate_series()

2008-04-30 Thread H . Harada
Here's the sync and updated patch.
It contains "strict" in catalog as well.

Hitoshi Harada

2008/4/24 H. Harada <[EMAIL PROTECTED]>:
> 2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>:
>
> > H.Harada escribió:
>  >
>  >
>  >  > # This is my first time to send a patch. If I did something wrong, I
>  >  > appreciate your pointing me out.
>  >
>  >  Brace positioning is off w.r.t. our conventions -- please fix that and
>  >  resubmit.
>
>  Here's updated version. Thanks for your advice.
>
>  Hitoshi Harada
>
>  2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>:
>
>
> > H.Harada escribió:
>  >
>  >
>  >  > # This is my first time to send a patch. If I did something wrong, I
>  >  > appreciate your pointing me out.
>  >
>  >  Brace positioning is off w.r.t. our conventions -- please fix that and
>  >  resubmit.
>  >
>  >  I have added this patch to the May commitfest.
>  >
>  >  --
>  >  Alvaro Herrera
> http://www.CommandPrompt.com/
>  >  The PostgreSQL Company - Command Prompt, Inc.
>  >
>


generate_series_timestamp.20080501.patch.gz
Description: GNU Zip compressed data

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width

2008-04-30 Thread Gregory Stark
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:

> The fact that it's wrapped is not a new format in itself, just a property of
> the aligned format.

Well I agree I just don't see any benefit to presenting it that way. I mean,
sure "wrapped" means "aligned and wrapped", but it's just shorthand notation
anyways.

In fact, it seems the only reason to separate the two like you're describing
would be if it *were* possible to have a wrapped html. Then your notation
could handle things "\pset format wrapped" couldn't:

\pset format html:autowrap

But I think we agree that isn't happening so why spell it "aligned:autowrap"
instead of just "wrap"?

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width

2008-04-30 Thread Alvaro Herrera
Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:

> > I think that could be fixed easily by having the syntax be something
> > like
> >
> > \pset format aligned:80
> > \pset format aligned:autowrap
> 
> I suppose. It seems kind of inconvenient though, what advantage does it have?

Over what?

I think having a separate "\pset format wrapped" does not make much
sense.  The fact that it's wrapped is not a new format in itself, just a
property of the aligned format.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


[PATCHES] libpq object hooks

2008-04-30 Thread Merlin Moncure
Attached is an updated version of  'libpq object hooks'.  The primary
purpose for libpq object hooks is to support our libpqtypes system
(not attached), but could possibly some nice sideband features to
libpq.  We are hoping to sneak this into the May commit fest.

regards,
merlin
Index: exports.txt
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.19
diff -C6 -r1.19 exports.txt
*** exports.txt	19 Mar 2008 00:39:33 -	1.19
--- exports.txt	30 Apr 2008 20:05:25 -
***
*** 138,143 
--- 138,150 
  PQsendDescribePortal  136
  lo_truncate   137
  PQconnectionUsedPassword  138
  pg_valid_server_encoding_id 139
  PQconnectionNeedsPassword 140
  lo_import_with_oid		  141
+ PQcopyResult  142
+ PQsetvalue143
+ PQresultAlloc 144
+ PQaddObjectHooks  145
+ PQaddGlobalObjectHooks146
+ PQhookData147
+ PQresultHookData  148
\ No newline at end of file
Index: fe-connect.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.357
diff -C6 -r1.357 fe-connect.c
*** fe-connect.c	31 Mar 2008 02:43:14 -	1.357
--- fe-connect.c	30 Apr 2008 20:05:25 -
***
*** 241,253 
   PQExpBuffer errorMessage);
  static char *pwdfMatchesString(char *buf, char *token);
  static char *PasswordFromFile(char *hostname, char *port, char *dbname,
   char *username);
  static void default_threadlock(int acquire);
  
- 
  /* global variable because fe-auth.c needs to access it */
  pgthreadlock_t pg_g_threadlock = default_threadlock;
  
  
  /*
   *		Connecting to a Database
--- 241,252 
***
*** 979,990 
--- 978,990 
   *	 o	If your backend wants to use Kerberos authentication then you must
   *		supply both a host name and a host address, otherwise this function
   *		may block on gethostname.
   *
   * 
   */
+ 
  PostgresPollingStatusType
  PQconnectPoll(PGconn *conn)
  {
  	PGresult   *res;
  	char		sebuf[256];
  
***
*** 998,1009 
--- 998,1010 
  			 * We really shouldn't have been polled in these two cases, but we
  			 * can handle it.
  			 */
  		case CONNECTION_BAD:
  			return PGRES_POLLING_FAILED;
  		case CONNECTION_OK:
+ 			pqInitObjectHooks(conn);
  			return PGRES_POLLING_OK;
  
  			/* These are reading states */
  		case CONNECTION_AWAITING_RESPONSE:
  		case CONNECTION_AUTH_OK:
  			{
***
*** 1816,1827 
--- 1817,1829 
  	conn->next_eo = EnvironmentOptions;
  	return PGRES_POLLING_WRITING;
  }
  
  /* Otherwise, we are open for business! */
  conn->status = CONNECTION_OK;
+ pqInitObjectHooks(conn);
  return PGRES_POLLING_OK;
  			}
  
  		case CONNECTION_SETENV:
  
  			/*
***
*** 1848,1859 
--- 1850,1862 
  default:
  	goto error_return;
  			}
  
  			/* We are open for business! */
  			conn->status = CONNECTION_OK;
+ 			pqInitObjectHooks(conn);
  			return PGRES_POLLING_OK;
  
  		default:
  			printfPQExpBuffer(&conn->errorMessage,
  			  libpq_gettext(
  			"invalid connection state %c, "
***
*** 1875,1887 
  	 * the connection structure must be freed).
  	 */
  	conn->status = CONNECTION_BAD;
  	return PGRES_POLLING_FAILED;
  }
  
- 
  /*
   * makeEmptyPGconn
   *	 - create a PGconn data structure with (as yet) no interesting data
   */
  static PGconn *
  makeEmptyPGconn(void)
--- 1878,1889 
***
*** 1970,1981 
--- 1972,2001 
   * release data that is to be held for the life of the PGconn structure.
   * If a value ought to be cleared/freed during PQreset(), do it there not here.
   */
  static void
  freePGconn(PGconn *conn)
  {
+ 	int i;
+ 
+ 	for(i=0; i < conn->objHooksCount; i++)
+ 	{
+ 		if(conn->objHooks[i].connDestroy)
+ 		{
+ 			conn->objHooks[i].connDestroy((const PGconn *)conn);
+ 			free(conn->objHooks[i].name);
+ 		}
+ 	}
+ 
+ 	if(conn->objHooks)
+ 	{
+ 		free(conn->objHooks);
+ 		conn->objHooks = NULL;
+ 		conn->objHooksCount = conn->objHooksSize = 0;
+ 	}
+ 
  	if (conn->pghost)
  		free(conn->pghost);
  	if (conn->pghostaddr)
  		free(conn->pghostaddr);
  	if (conn->pgport)
  		free(conn->pgport);
***
*** 2151,2164 
  PQreset(PGconn *conn)
  {
  	if (conn)
  	{
  		closePGconn(conn);
  
! 		if (connectDBStart(conn))
! 			(void) connectDBComplete(conn);
  	}
  }
  
  
  /*
   * PQresetStart:
--- 2171,2189 
  PQreset(PGconn *conn)
  {
  	if (conn)
  	{
  		closePGconn(conn);
  
! 		if (connectDBStart(conn) && connectDBComplete(conn))
! 		{
! 			int i;
! 			for(i=0; i < conn->objHooksCount; i++)
! if(conn->objHooks[i].connReset)
! 	conn->objHooks[i].connReset((const PGconn *)conn);
! 		}
  	}
  }
  
  
  /*
   * PQresetStart:
***
*** 21

Re: [PATCHES] pg_postmaster_reload_time() patch

2008-04-30 Thread George Gensure
On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> George Gensure escribió:
>
>
> > I've done a quick write up for reload time reporting from the
>  > administration TODO.  I was a little paranoid with the locking, but
>  > didn't want problems to occur with signals on the postmaster and the
>  > read side.
>
>  I'd say too much -- postmaster runs with signals blocked all the time
>  (except during select()) so this is not necessary there.
>
>  Regarding the locking on backends, I admit I am not sure if this is
>  really a problem enough that you need a spinlock for it.  Anyway we tend
>  not to use spinlocks too much -- probably an LWLock would be more
>  apropos, if a lock is really needed.  (A bigger question is whether the
>  reload time should be local for each backend, or exposed globally
>  through MyProc.  I don't think it's interesting enough to warrant that,
>  but perhaps others think differently.)
>
>  Lastly, I didn't read the patch close enough to tell if it would work on
>  both the EXEC_BACKEND case and the regular one.
>
>  --
>  Alvaro Herrerahttp://www.CommandPrompt.com/
>  The PostgreSQL Company - Command Prompt, Inc.
>

I've reworked the patch in response to comments.

The new function name is pg_conf_load_time()
I'm now using LWLocks only on the backend in order to protect the
PgReloadTime from mid copy reads.  This may prove to be unnecessary,
since the code to handle HUPs seems to be executed synchronously on
the backend, but I'll let someone else tell me its safe before
removing it.

-George
*** ./doc/src/sgml/func.sgml.orig	2008-04-29 23:47:39.378726574 -0400
--- ./doc/src/sgml/func.sgml	2008-04-30 11:31:38.434893712 -0400
***
*** 10892,10897 
--- 10892,10903 

  

+pg_conf_load_time()
+timestamp with time zone
+config load time
+   
+ 
+   
 session_user
 name
 session user name
***
*** 11037,11042 
--- 11043,11062 
 
  
 
+ pg_conf_load_time
+
+ 
+
+  pg_conf_load_time returns the
+  timestamp with time zone when the
+  config was last loaded for this session.
+
+ 
+
+ version
+
+ 
+
  version
 
  
*** ./src/backend/postmaster/postmaster.c.orig	2008-04-29 23:48:07.374455697 -0400
--- ./src/backend/postmaster/postmaster.c	2008-04-30 12:02:05.156215936 -0400
***
*** 390,395 
--- 390,396 
  	InheritableSocket pgStatSock;
  	pid_t		PostmasterPid;
  	TimestampTz PgStartTime;
+ 	TimestampTz PgReloadTime;
  	bool		redirection_done;
  #ifdef WIN32
  	HANDLE		PostmasterHandle;
***
*** 1008,1013 
--- 1009,1015 
  	 * Remember postmaster startup time
  	 */
  	PgStartTime = GetCurrentTimestamp();
+ 	PgReloadTime = PgStartTime;
  	/* PostmasterRandom wants its own copy */
  	gettimeofday(&random_start_time, NULL);
  
***
*** 1931,1936 
--- 1933,1943 
  		/* Update the starting-point file for future children */
  		write_nondefault_variables(PGC_SIGHUP);
  #endif
+ 
+ 		/*
+ 		 * Remember config load time
+ 		 */
+ 		PgReloadTime = GetCurrentTimestamp();
  	}
  
  	PG_SETMASK(&UnBlockSig);
***
*** 4263,4268 
--- 4270,4276 
  
  	param->PostmasterPid = PostmasterPid;
  	param->PgStartTime = PgStartTime;
+ 	param->PgReloadTime = PgReloadTime;
  
  	param->redirection_done = redirection_done;
  
*** ./src/backend/tcop/postgres.c.orig	2008-04-29 23:48:58.866600196 -0400
--- ./src/backend/tcop/postgres.c	2008-04-30 12:21:40.476913468 -0400
***
*** 58,63 
--- 58,64 
  #include "storage/ipc.h"
  #include "storage/proc.h"
  #include "storage/sinval.h"
+ #include "storage/spin.h"
  #include "tcop/fastpath.h"
  #include "tcop/pquery.h"
  #include "tcop/tcopprot.h"
***
*** 3375,3380 
--- 3376,3382 
  	 */
  	if (!IsUnderPostmaster)
  		PgStartTime = GetCurrentTimestamp();
+ 	PgReloadTime = PgStartTime;
  
  	/*
  	 * POSTGRES main processing loop begins here
***
*** 3550,3555 
--- 3552,3564 
  		{
  			got_SIGHUP = false;
  			ProcessConfigFile(PGC_SIGHUP);
+ 
+ 			/*
+ 			 * Remember config load time
+ 			 */
+ 			LWLockAcquire(ReloadTimeLock, LW_EXCLUSIVE);
+ 			PgReloadTime = GetCurrentTimestamp();
+ 			LWLockRelease(ReloadTimeLock);
  		}
  
  		/*
*** ./src/backend/utils/adt/timestamp.c.orig	2008-04-29 23:49:46.359354923 -0400
--- ./src/backend/utils/adt/timestamp.c	2008-04-30 12:23:52.456779063 -0400
***
*** 42,47 
--- 42,49 
  
  /* Set at postmaster start */
  TimestampTz PgStartTime;
+ /* Set at configuration reload */
+ TimestampTz PgReloadTime;
  
  
  static TimeOffset time2t(const int hour, const int min, const int sec, const fsec_t fsec);
***
*** 1162,1167 
--- 1164,1179 
  	PG_RETURN_TIMESTAMPTZ(PgStartTime);
  }
  
+ Datum
+ pgsql_conf_load_time(PG_FUNCTION_ARGS)
+ {
+ 	TimestampTz ti

Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread Simon Riggs
On Wed, 2008-04-30 at 08:29 -0700, David Fetter wrote:
> On Wed, Apr 30, 2008 at 03:43:54PM +0100, Simon Riggs wrote:
> > On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote:
> > > On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote:
> > > > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > > > > This could be implemented by a "pass-through" restore_command,
> > > > > that calls pg_standby, and does the custom action when
> > > > > pg_standby returns successfully. 
> > > > 
> > > > Yes, that's the preferred route for most cases.
> > > > 
> > > > pg_standby was designed to be customisable, so if it works for
> > > > Chris, thats OK.
> > > > 
> > > > After some mulling on this, I'm not sure we need to include this
> > > > in pg_standby however. If we did we'd end up having before/after
> > > > commands and retry options etc.
> > > 
> > > Would those be good things to have as a whole package?
> > 
> > I think the answer is we already do. It's called bash.
> 
> Just a stray thought...bash doesn't run very well on common Windows
> installations.

True, but you can run anything you choose...

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread David Fetter
On Wed, Apr 30, 2008 at 03:43:54PM +0100, Simon Riggs wrote:
> On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote:
> > On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote:
> > > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > > > This could be implemented by a "pass-through" restore_command,
> > > > that calls pg_standby, and does the custom action when
> > > > pg_standby returns successfully. 
> > > 
> > > Yes, that's the preferred route for most cases.
> > > 
> > > pg_standby was designed to be customisable, so if it works for
> > > Chris, thats OK.
> > > 
> > > After some mulling on this, I'm not sure we need to include this
> > > in pg_standby however. If we did we'd end up having before/after
> > > commands and retry options etc.
> > 
> > Would those be good things to have as a whole package?
> 
> I think the answer is we already do. It's called bash.

Just a stray thought...bash doesn't run very well on common Windows
installations.

Cheers,
David.
-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: [EMAIL PROTECTED]

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread Simon Riggs
On Wed, 2008-04-30 at 07:31 -0700, David Fetter wrote:
> On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote:
> > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > > This could be implemented by a "pass-through" restore_command,
> > > that calls pg_standby, and does the custom action when pg_standby
> > > returns successfully. 
> > 
> > Yes, that's the preferred route for most cases.
> > 
> > pg_standby was designed to be customisable, so if it works for
> > Chris, thats OK.
> > 
> > After some mulling on this, I'm not sure we need to include this in
> > pg_standby however. If we did we'd end up having before/after
> > commands and retry options etc.
> 
> Would those be good things to have as a whole package?

I think the answer is we already do. It's called bash.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread David Fetter
On Wed, Apr 30, 2008 at 12:49:44PM +0100, Simon Riggs wrote:
> On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > This could be implemented by a "pass-through" restore_command,
> > that calls pg_standby, and does the custom action when pg_standby
> > returns successfully. 
> 
> Yes, that's the preferred route for most cases.
> 
> pg_standby was designed to be customisable, so if it works for
> Chris, thats OK.
> 
> After some mulling on this, I'm not sure we need to include this in
> pg_standby however. If we did we'd end up having before/after
> commands and retry options etc.

Would those be good things to have as a whole package?

Cheers,
David.
-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: [EMAIL PROTECTED]

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


[PATCHES] fix for pl/pythons named OUT parameter handling

2008-04-30 Thread Hannu Krosing
Before this patch, pl/python will not do the right thing if OUT
parameters are present


Hannu

Index: plpython/plpython.c
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.106
diff -c -r1.106 plpython.c
*** plpython/plpython.c	2 Jan 2008 03:10:27 -	1.106
--- plpython/plpython.c	29 Apr 2008 20:40:53 -
***
*** 1159,1167 
  	bool		isnull;
  	int			i,
  rv;
- 	Datum		argnames;
- 	Datum	   *elems;
- 	int			nelems;
  
  	procStruct = (Form_pg_proc) GETSTRUCT(procTup);
  
--- 1159,1164 
***
*** 1250,1304 
  		 * now get information required for input conversion of the
  		 * procedure's arguments.
  		 */
! 		proc->nargs = procStruct->pronargs;
! 		if (proc->nargs)
! 		{
! 			argnames = SysCacheGetAttr(PROCOID, procTup, Anum_pg_proc_proargnames, &isnull);
! 			if (!isnull)
! 			{
! /* XXX this code is WRONG if there are any output arguments */
! deconstruct_array(DatumGetArrayTypeP(argnames), TEXTOID, -1, false, 'i',
!   &elems, NULL, &nelems);
! if (nelems != proc->nargs)
! 	elog(ERROR,
! 		 "proargnames must have the same number of elements "
! 		 "as the function has arguments");
! proc->argnames = (char **) PLy_malloc(sizeof(char *) * proc->nargs);
! memset(proc->argnames, 0, sizeof(char *) * proc->nargs);
! 			}
! 		}
! 		for (i = 0; i < proc->nargs; i++)
! 		{
  			HeapTuple	argTypeTup;
  			Form_pg_type argTypeStruct;
  
! 			argTypeTup = SearchSysCache(TYPEOID,
! 		 ObjectIdGetDatum(procStruct->proargtypes.values[i]),
! 		0, 0, 0);
! 			if (!HeapTupleIsValid(argTypeTup))
! elog(ERROR, "cache lookup failed for type %u",
! 	 procStruct->proargtypes.values[i]);
! 			argTypeStruct = (Form_pg_type) GETSTRUCT(argTypeTup);
  
! 			/* Disallow pseudotype argument */
! 			if (argTypeStruct->typtype == TYPTYPE_PSEUDO)
! ereport(ERROR,
! 		(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! 		 errmsg("plpython functions cannot take type %s",
! 		format_type_be(procStruct->proargtypes.values[i];
! 
! 			if (argTypeStruct->typtype != TYPTYPE_COMPOSITE)
! PLy_input_datum_func(&(proc->args[i]),
! 	 procStruct->proargtypes.values[i],
! 	 argTypeTup);
! 			else
! proc->args[i].is_rowtype = 2;	/* still need to set I/O funcs */
  
! 			ReleaseSysCache(argTypeTup);
  
! 			/* Fetch argument name */
! 			if (proc->argnames)
! proc->argnames[i] = PLy_strdup(DatumGetCString(DirectFunctionCall1(textout, elems[i])));
  		}
  
  		/*
--- 1247,1309 
  		 * now get information required for input conversion of the
  		 * procedure's arguments.
  		 */
! 
! 		if (procStruct->pronargs) {
  			HeapTuple	argTypeTup;
  			Form_pg_type argTypeStruct;
  
! 			Oid		*types;
! 			char   **names,
! 	*modes;
! 			int		 i,
! 	 pos,
! 	 total;
! 
! 			total = get_func_arg_info(procTup, &types, &names, &modes);
! 			if (modes == NULL) 
! proc->nargs = procStruct->pronargs;
! 			else 
! 			/* count number of 'i?' args into proc->nargs*/
! for (i = 0;i < total;i++) {
! 	if (modes[i] != 'o') (proc->nargs)++;
! }
  
! 			proc->argnames = (char **) PLy_malloc(sizeof(char *) * proc->nargs);
! 			for (i = pos = 0;i < total;i++) {
! if (modes && modes[i] == 'o') /* skip OUT arguments */
! 	continue;
! 
! Assert(types[i] == procStruct->proargtypes.values[i]);
! 
! argTypeTup = SearchSysCache(TYPEOID,ObjectIdGetDatum(types[i]), 0, 0, 0);
! if (!HeapTupleIsValid(argTypeTup))
! 	elog(ERROR, "cache lookup failed for type %u",
! 		 procStruct->proargtypes.values[i]);
! argTypeStruct = (Form_pg_type) GETSTRUCT(argTypeTup);
! 
! switch (argTypeStruct->typtype) {
! 	case TYPTYPE_PSEUDO:
! 		ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
!  errmsg("plpython functions cannot take type %s",
!  format_type_be(types[i];
! 	case TYPTYPE_COMPOSITE:
! 		proc->args[pos].is_rowtype = 2; /* set IO funcs at first call*/
! 		break;
! 	default:
! 		PLy_input_datum_func(&(proc->args[pos]),
! 			 types[i],
! 			 argTypeTup);
! }
  
! ReleaseSysCache(argTypeTup);
  
! /* get argument name */
! proc->argnames[pos] = names ? PLy_strdup(names[i]) : NULL; 
! 
! pos++;
! 
! 			}
  		}
  
  		/*
Index: plpython/expected/plpython_function.out
===
RCS file: /projects/cvsroot/pgsql/src/pl/plpython/expected/plpython_function.out,v
retrieving revision 1.10
diff -c -r1.10 plpython_function.out
*** plpython/expected/plpython_function.out	16 Oct 2006 21:13:57 -	1.10
--- plpython/expected/plpython_function.out	29 Apr 2008 20:40:59 -
***
*** 436,438 
--- 436,447 
  	type_record.second = second
  	return type_record
  $$ LANGUAGE plpythonu;
+ CREATE FUNCTION test_in_out_params(f

Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread chris . johnson
Simon Riggs <[EMAIL PROTECTED]> wrote on 04/30/2008 07:49:44 AM:

> On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > [EMAIL PROTECTED] wrote:
> > > When using pg_standby to remain in recovery mode on a warm standby
system,
> > > if there is a need to perform other actions in coordination with
recovery
> > > actions, the -x  option implemented by this patch
> > > enables that coordination.  I considered adding the ability to
> override the
> > > restoreCommand, however by keeping this separate and optional it is
> > > possible to force retries of the auxiliary command until successful
and
> > > still utilize pg_usleep instead of looping within an external script
or
> > > command.  And the previous behavior of pg_standby remains unchanged
(other
> > > than debug logging and documenting the option in usage) if the new
option
> > > is omitted.
> > >
> > > I added this feature to help with synchronization of a content
repository
> > > consisting of a PostgreSQL db for meta-information and a separate
file
> > > store for content.
> > > The auxiliary command enables forcing an rsync of the file storethat
is at
> > > least as current as the found WAL segment file's db changes, and
prevents
> > > recovery of that WAL file unless the rsync can be performed
successfully.
> > >
> > > (See attached file: pg_standby.c.diff)
> >
> > This could be implemented by a "pass-through" restore_command, that
> > calls pg_standby, and does the custom action when pg_standby returns
> > successfully.
>
> Yes, that's the preferred route for most cases.
>
> pg_standby was designed to be customisable, so if it works for Chris,
> thats OK.
>
> After some mulling on this, I'm not sure we need to include this in
> pg_standby however. If we did we'd end up having before/after commands
> and retry options etc.
>
> --
>   Simon Riggs
>   2ndQuadrant  http://www.2ndQuadrant.com
>
I did not wish to presume that the WAL file being copied or linked into the
destination would cause no issues should the engine be shutdown during my
custom action or retry loop, and subsequently restarted in recovery mode.
Which is why I chose to insert executing the command after determining that
the file was available, but before the mv/cp.  I like your suggestion of
before/after commands and retry options.  It offers flexibility in
pg_standby far beyond my specific needs.

Not having studied internals of postgres I am not sure, but it seemed to me
that the other value provided by this implementation instead of a
'pass-through' restore command is the use of pg_usleep in retry loops.  If
pg_standby were not to provide that retry loop for the after command, then
another program would need to be written to do that.  Adding the feature to
pg_standby seemed the more elegant implementation.  But if pg_usleep
accomplishes nothing more than a sleep in a script would, then implementing
the loop in pg_standby provides a trivial advantage.

Chris


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Documentation: ALTER ROLE - no password

2008-04-30 Thread Alvaro Herrera
Andreas 'ads' Scherbaum wrote:
> 
> Hello,
> 
> i've seen the question "how to remove a password" now several times in
> the last weeks. Attached is a small patch which add a new example for
> the "ALTER ROLE" documentation.

Applied, thanks.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] pg_postmaster_reload_time() patch

2008-04-30 Thread Alvaro Herrera
George Gensure escribió:
> I've done a quick write up for reload time reporting from the
> administration TODO.  I was a little paranoid with the locking, but
> didn't want problems to occur with signals on the postmaster and the
> read side.

I'd say too much -- postmaster runs with signals blocked all the time
(except during select()) so this is not necessary there.

Regarding the locking on backends, I admit I am not sure if this is
really a problem enough that you need a spinlock for it.  Anyway we tend
not to use spinlocks too much -- probably an LWLock would be more
apropos, if a lock is really needed.  (A bigger question is whether the
reload time should be local for each backend, or exposed globally
through MyProc.  I don't think it's interesting enough to warrant that,
but perhaps others think differently.)

Lastly, I didn't read the patch close enough to tell if it would work on
both the EXEC_BACKEND case and the regular one.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread Simon Riggs
On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> [EMAIL PROTECTED] wrote:
> > When using pg_standby to remain in recovery mode on a warm standby system,
> > if there is a need to perform other actions in coordination with recovery
> > actions, the -x  option implemented by this patch
> > enables that coordination.  I considered adding the ability to override the
> > restoreCommand, however by keeping this separate and optional it is
> > possible to force retries of the auxiliary command until successful and
> > still utilize pg_usleep instead of looping within an external script or
> > command.  And the previous behavior of pg_standby remains unchanged (other
> > than debug logging and documenting the option in usage) if the new option
> > is omitted.
> > 
> > I added this feature to help with synchronization of a content repository
> > consisting of a PostgreSQL db for meta-information and a separate file
> > store for content.
> > The auxiliary command enables forcing an rsync of the file store that is at
> > least as current as the found WAL segment file's db changes, and prevents
> > recovery of that WAL file unless the rsync can be performed successfully.
> > 
> > (See attached file: pg_standby.c.diff)
> 
> This could be implemented by a "pass-through" restore_command, that 
> calls pg_standby, and does the custom action when pg_standby returns 
> successfully. 

Yes, that's the preferred route for most cases.

pg_standby was designed to be customisable, so if it works for Chris,
thats OK.

After some mulling on this, I'm not sure we need to include this in
pg_standby however. If we did we'd end up having before/after commands
and retry options etc.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] Patch to add a feature to pg_standby

2008-04-30 Thread Heikki Linnakangas

[EMAIL PROTECTED] wrote:

When using pg_standby to remain in recovery mode on a warm standby system,
if there is a need to perform other actions in coordination with recovery
actions, the -x  option implemented by this patch
enables that coordination.  I considered adding the ability to override the
restoreCommand, however by keeping this separate and optional it is
possible to force retries of the auxiliary command until successful and
still utilize pg_usleep instead of looping within an external script or
command.  And the previous behavior of pg_standby remains unchanged (other
than debug logging and documenting the option in usage) if the new option
is omitted.

I added this feature to help with synchronization of a content repository
consisting of a PostgreSQL db for meta-information and a separate file
store for content.
The auxiliary command enables forcing an rsync of the file store that is at
least as current as the found WAL segment file's db changes, and prevents
recovery of that WAL file unless the rsync can be performed successfully.

(See attached file: pg_standby.c.diff)


This could be implemented by a "pass-through" restore_command, that 
calls pg_standby, and does the custom action when pg_standby returns 
successfully. Or perhaps you could run the custom action in whatever 
script is copying the files to the directory.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches


Re: [PATCHES] pg_postmaster_reload_time() patch

2008-04-30 Thread Heikki Linnakangas

Gurjeet Singh wrote:

On Wed, Apr 30, 2008 at 9:53 AM, George Gensure <[EMAIL PROTECTED]> wrote:


I've done a quick write up for reload time reporting from the
administration TODO.  I was a little paranoid with the locking, but
didn't want problems to occur with signals on the postmaster and the
read side.



IMHO, the function should return NULL if the postmaster never reloaded; that
is, it was started, but never signaled to reload.


I think it's useful to get the server startup time if the configuration 
has never been reloaded. That's when the configuration was loaded, if no 
reload has been triggered since. Perhaps the function should be named to 
reflect that better. pg_configuration_load_time() ?


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches