Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

2007-03-06 Thread Peter Eisentraut
Mike Rylander wrote:
 The patch adds support for default XML namespaces in xml2 by providing
 a mechanism for supplying a prefix to a named namespace URI.

How does it support multiple namespaces in one document?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

2007-03-06 Thread Nikolay Samokhvalov

On 3/6/07, Mike Rylander [EMAIL PROTECTED] wrote:

Attatched you'll find a patch that I've been kicking around for a
while that I'd like to propose for inclusion in 8.3.  I attempted to
submit this through the original xml2 author (as far back as the  7.4
days) but got no response.

It's really fairly trivial, but I will be using the features it
provides in production soon, so I'd like to see it applied against the
contrib xml2 module.  The patch adds support for default XML
namespaces in xml2 by providing a mechanism for supplying a prefix to
a named namespace URI.  It then wraps the namespace-capable functions
in backward-compatible equivalents so that old code will not break.


1) And what about non-default namespaces?
2) What if my XPath query has different prefix, that also should be
mapped to the same URI? (Not frequent case, but this really can occur
-- e.g. XML doc has prefix 'local' for URI='http://127.0.0.1', but
XPath should have 'loc' for the same URI.)

--
Best regards,
Nikolay

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


[PATCHES] doc patch for Linux memory overcommit

2007-03-06 Thread Toru SHIMOGAKI

The attached is a doc patch for Linux memory overcommit and an additional way of
avoiding a problem that postmaster is suddenly killed by OOM-Killer.

http://archives.postgresql.org/pgsql-docs/2007-03/msg0.php

Best regards,

-- 
Toru SHIMOGAKI[EMAIL PROTECTED]
*** runtime.sgml.orig   2007-03-06 16:23:10.0 +0900
--- runtime.sgml2007-03-06 17:14:38.0 +0900
***
*** 1207,1215 
 /para
  
 para
! On Linux 2.6 and later, a better solution is to modify the kernel's
! behavior so that it will not quoteovercommit/ memory.  This is
! done by selecting strict overcommit mode via commandsysctl/command:
  programlisting
  sysctl -w vm.overcommit_memory=2
  /programlisting
--- 1207,1224 
 /para
  
 para
! In addition, increasing swap area on OS can avoid the problem too.
! Out-of-Memory-Killer(OOM-Killer) is invoked whenever physical memory and 
! swap area are exhausted. Increasing swap area is easy to set and it 
! doesn't have harmful influence.
!/para
! 
!para
! On Linux 2.6 and later, a better solution is to modify the kernel's 
! behavior so that it will not quoteovercommit/ memory.  Though this 
! setting can't prevent OOM-Killer from invoking directly, we can expect 
! healty memory allocation. This is done by selecting strict overcommit 
! mode via commandsysctl/command:
  programlisting
  sysctl -w vm.overcommit_memory=2
  /programlisting

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] [DOCS] doc patch for Linux memory overcommit

2007-03-06 Thread Peter Eisentraut
Toru SHIMOGAKI wrote:
 The attached is a doc patch for Linux memory overcommit and an
 additional way of avoiding a problem that postmaster is suddenly
 killed by OOM-Killer.

The text needs some articles.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] [DOCS] doc patch for Linux memory overcommit

2007-03-06 Thread Peter Eisentraut
Toru SHIMOGAKI wrote:
 The attached is a doc patch for Linux memory overcommit and an
 additional way of avoiding a problem that postmaster is suddenly
 killed by OOM-Killer.

Patch installed.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

2007-03-06 Thread Mike Rylander

On 3/6/07, Peter Eisentraut [EMAIL PROTECTED] wrote:

Mike Rylander wrote:
 The patch adds support for default XML namespaces in xml2 by providing
 a mechanism for supplying a prefix to a named namespace URI.

How does it support multiple namespaces in one document?


It supports one default (unprefixed) namespace URI per document, which
ISTM is the overwhelmingly common case (and the itch that I must
scratch).

--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

2007-03-06 Thread Mike Rylander

On 3/6/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:

On 3/6/07, Mike Rylander [EMAIL PROTECTED] wrote:
 Attatched you'll find a patch that I've been kicking around for a
 while that I'd like to propose for inclusion in 8.3.  I attempted to
 submit this through the original xml2 author (as far back as the  7.4
 days) but got no response.

 It's really fairly trivial, but I will be using the features it
 provides in production soon, so I'd like to see it applied against the
 contrib xml2 module.  The patch adds support for default XML
 namespaces in xml2 by providing a mechanism for supplying a prefix to
 a named namespace URI.  It then wraps the namespace-capable functions
 in backward-compatible equivalents so that old code will not break.

1) And what about non-default namespaces?


I'm not sure I understand.  If the namespace already has a prefix then
it works fine.  This patch simply gives a known non-prefixed namespace
URI a prefix so one can write XPath that looks like

 //marc:[EMAIL PROTECTED]'245']/marc:[EMAIL PROTECTED]'a']

instead of

 //*[local-name()='datafield' and
@tag='245']/*[local-name()='subfied' and @code='a']

A little two node example is painful enough, now imagine a non-trivial
example with backtracking conditionals... :P


2) What if my XPath query has different prefix, that also should be
mapped to the same URI? (Not frequent case, but this really can occur
-- e.g. XML doc has prefix 'local' for URI='http://127.0.0.1', but
XPath should have 'loc' for the same URI.)



Both prefixes work fine as multiple prefixes can map to the same URI.


--
Best regards,
Nikolay




--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [PATCHES] Heap page diagnostic/test functions (WIP)

2007-03-06 Thread Simon Riggs
On Tue, 2007-03-06 at 09:33 +0530, Pavan Deolasee wrote:
 Simon Riggs wrote:
  I'll happily code it as functions or system cols or any other way, as
  long as we can see everything there is to see.

 With HOT, other useful information is about the line pointers. 

Done

 It would be
 cool to be able to print the redirection info, details about LP_DELETEd
 line pointers etc. Also, there are some flags in the t_infomask2 which HOT
 uses, so that information would be useful also.

I'll return the infomasks directly, for you to manipulate.

Not happy with that, but open to suggestions.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



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


Re: [PATCHES] Heap page diagnostic/test functions (WIP)

2007-03-06 Thread Gregory Stark
Simon Riggs [EMAIL PROTECTED] writes:

 I'll return the infomasks directly, for you to manipulate.

 Not happy with that, but open to suggestions.

Well the alternative would be a long list of boolean columns which would make
the output kind of long.

Perhaps a function pg_decode_infomask(varbit) which returns a ROW of booleans
with appropriate names would be a good compromise. If you want it you could
use it in your query.

Or perhaps you could include a ROW of booleans in your output already,
something like:

postgres=# insert into tuple_info values (b'000', ROW(false,false,false));
INSERT 0 1

postgres=# select * from tuple_info;
 infomask_bits | infomask_flags 
---+
 000   | (f,f,f)
(1 row)

postgres=# select (infomask_flags).* from tuple_info;
 flag_a | flag_b | flag_c 
++
 f  | f  | f
(1 row)

That might be kind of tricky to cons up though. I had to create a table to do
it here. 

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

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


Re: [PATCHES] Heap page diagnostic/test functions (WIP)

2007-03-06 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes:
 Simon Riggs [EMAIL PROTECTED] writes:
 I'll return the infomasks directly, for you to manipulate.
 
 Not happy with that, but open to suggestions.

 Well the alternative would be a long list of boolean columns which would make
 the output kind of long.

 Perhaps a function pg_decode_infomask(varbit) which returns a ROW of booleans
 with appropriate names would be a good compromise. If you want it you could
 use it in your query.

This is pointless --- the function is already intended only for
debugging considerations, and anyone who needs it can be assumed capable
of ANDing with a bitmask or whatever he needs to do to inspect the
values.  I don't see anyone asking for pretty display of cmin, say,
and yet that's certainly not that easy to interpret either.

As for masks plural, I'd be inclined to merge them into one 32-bit
result --- the distinction between flag bits in infomask and infomask2
is at this point entirely historical.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


[PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support

2007-03-06 Thread Trevor Hardcastle

Greetings all,

I wrote this patch about a week ago to introduce myself to coding on 
PostgreSQL. I wasn't entirely sure what the 'INCLUDING INDEXES' option 
was meant to do, so I held off submitting it until I could get around to 
asking about that and tweaking the documentation to reflect the patch. 
By useful coincidence the thread Auto creation of Partitions had this 
post in it, which made the intent of the option clear enough for me to 
go ahead and see what people think of this.


Gregory Stark wrote:

NikhilS [EMAIL PROTECTED] writes:

  

the intention is to use this information from the parent and make it a
property of the child table. This will avoid the step for the user having to
manually specify CREATE INDEX and the likes on all the children tables
one-by-one.



Missed the start of this thread. A while back I had intended to add WITH
INDEXES to CREATE TABLE LIKE. That would let you create a tale LIKE parent
WITH CONSTRAINTS WITH INDEXES and get pretty much a perfect table ready for
adding to the inheritance structure.


  
So, that's what this patch does. When a table is created with 'CREATE 
TABLE ... LIKE parent INCLUDING INDEXES'  this iterates over the parent 
table indexes looking for constraint indexes, and alters the  
CreateStmtContext to include equivalent indexes on the child table.


This is probably a somewhat naive implementation, being a first attempt. 
I wasn't sure what sort of lock to place on the parent indexes or what 
tablespace the new indexes should be created in. Any help improving it 
would be appreciated.


Thank you,
-Trevor Hardcastle

Index: src/backend/parser/analyze.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/analyze.c,v
retrieving revision 1.361
diff -c -r1.361 analyze.c
*** src/backend/parser/analyze.c20 Feb 2007 17:32:16 -  1.361
--- src/backend/parser/analyze.c7 Mar 2007 01:43:12 -
***
*** 14,19 
--- 14,20 
  #include postgres.h
  
  #include access/heapam.h
+ #include access/genam.h
  #include catalog/heap.h
  #include catalog/index.h
  #include catalog/namespace.h
***
*** 40,45 
--- 41,47 
  #include utils/acl.h
  #include utils/builtins.h
  #include utils/lsyscache.h
+ #include utils/relcache.h
  #include utils/syscache.h
  
  
***
*** 1345,1355 
}
}
  
-   if (including_indexes)
-   ereport(ERROR,
-   (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-errmsg(LIKE INCLUDING INDEXES is not 
implemented)));
- 
/*
 * Insert the copied attributes into the cxt for the new table
 * definition.
--- 1347,1352 
***
*** 1448,1453 
--- 1445,1519 
}
  
/*
+* Clone constraint indexes if requested.
+*/
+   if (including_indexes  relation-rd_rel-relhasindex)
+   {
+   List   *parent_index_list = RelationGetIndexList(relation);
+   ListCell   *parent_index_scan;
+ 
+   foreach(parent_index_scan, parent_index_list)
+   {
+   Oidparent_index_oid = 
lfirst_oid(parent_index_scan);
+   Relation   parent_index;
+ 
+   parent_index = index_open(parent_index_oid, 
AccessShareLock);
+ 
+   /*
+* Create new unique or primary key indexes on the 
child.
+*/
+   if (parent_index-rd_index-indisunique || 
parent_index-rd_index-indisprimary)
+   {
+   IndexInfo  *parent_index_info;
+   Constraint *n = makeNode(Constraint);
+   AttrNumber  parent_attno;
+ 
+   parent_index_info = 
BuildIndexInfo(parent_index);
+ 
+   if (parent_index-rd_index-indisprimary)
+   {
+   n-contype = CONSTR_PRIMARY;
+   }
+   else
+   {
+   n-contype = CONSTR_UNIQUE;
+   }
+   /* Let DefineIndex name it */
+   n-name = NULL;
+   n-raw_expr = NULL;
+   n-cooked_expr = NULL;
+ 
+   /* 
+* Search through the possible index keys, and 
append 
+* the names of simple columns to the new index 
key list.
+*/
+   for (parent_attno = 1; parent_attno = 
parent_index-rd_att-natts;
+parent_attno++)
+