Re: [HACKERS] patches for items from TODO list
minor nit: the null attribute should take XMLSchema boolean type values:
{true, false, 1, 0}
More importantly, how do you handle array or record type fields? If they
are just opaque text I don't think that's what I at least would want
from XML output routines.
cheers
andrew
Christopher Kings-Lynne wrote:
I'm going to second Neil here. This feature becomes useful *only*
when there is a certified or de-facto universal standard XML
representation for database data. Then I could see a case for it.
But there isn't.
We've done it in phpPgAdmin (we made up our own standard), and a
couple of people use it. I also do not think that it should be in the
backend until there is a standard. Here is what phpPgAdmin produces
(note NULL handling):
?xml version=1.0 encoding=UTF-8 ?
data
header
column name=feature_id type=varchar /
column name=feature_name type=varchar /
column name=is_supported type=varchar /
column name=is_verified_by type=varchar /
column name=comments type=varchar /
/header
records
row
column name=feature_idPKG000/column
column name=feature_nameCore/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG001/column
column name=feature_nameEnhanced datetime
facilities/column
column name=is_supportedYES/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG002/column
column name=feature_nameEnhanced integrity
management/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG003/column
column name=feature_nameOLAP facilities/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG004/column
column name=feature_namePSM/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=commentsPL/pgSQL is similar./column
/row
row
column name=feature_idPKG005/column
column name=feature_nameCLI/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=commentsODBC is similar./column
/row
row
column name=feature_idPKG006/column
column name=feature_nameBasic object support/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG007/column
column name=feature_nameEnhanced object support/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG008/column
column name=feature_nameActive database/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=comments null=null/column
/row
row
column name=feature_idPKG010/column
column name=feature_nameOLAP/column
column name=is_supportedNO/column
column name=is_verified_by null=null/column
column name=commentsNO/column
/row
/records
/data
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---(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: [HACKERS] Two-phase commit issues
On Friday 20 May 2005 18:14, Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: As I remember, you said two-phase wasn't 100% reliable and we just needed a way to report failures. [ Shrug... ] I remain of the opinion that 2PC is a solution in search of a problem, because it does not solve the single point of failure issue (just moves same from the database to the 2PC controller). You're right. 2PC to coordinate replicas of the same data is not that interesting. It is however most interesting when coordination updates to different objects such as (i) a central database server and a local staging area or (ii) a database server and transactional queues in a workflow-style app. But some people want it anyway, and they aren't going to be satisfied that we are an enterprise grade database until we can check off this particular bullet point. As long as the implementation doesn't impose any significant costs when not being used (which AFAICS Heikki's method doesn't), I think we gotta hold our noses and do it. It is a definitly in the check list if you're shopping for a database to go with your buzzword compliant J2EE app server. :-) -- Jose Orlando Pereira ---(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: [HACKERS] Two-phase commit issues
On Thu, 19 May 2005, Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: * I'm inclined to think that the gid identifiers for prepared transactions ought to be SQL identifiers (names), not string literals. Was there a particular reason for making them strings? Sure. No Reason. While you're at it, do you think it's possible to make it unlimited size? I couldn't think of a simple way. Actually, one reason for wanting them to be identifiers is so that there's a principled reason for saying what the max length is ;-) I took a closer look at the JTA spec and saw that the Xid, which is translated to a gid in the jdbc driver, consists of a format identifier (32-bit int), a branch qualifier (max 64 bytes) and a global transaction identifier (max 64 bytes). That means that gid needs to hold 132 raw bytes minimum. Also, it would be nice if the driver could send the gid as a bytea, without converting it to a string. Similar to using parameter markers and parse / bind messages with regular queries. That would require a change in the FE/BE protocol, right? The branch qualifier and global transaction id structure comes from the OSI CCR specification. Anyone here that knows more about OSI CCR? - Heikki ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Minor issues with bitmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been playing with the new bitmap stuff, and so far, it seems to be working fairly well. I have two very minor complaints, however. First, some of my queries have a large number of OR conditions, and this is where the bitmap gets used a lot. However, the explain [analyze] plans are unnecessarily verbose: for each item in the OR list, I get two lines telling me a Bitmap Index Scan is being used on an index for that item, and a separate line indicating the Index condition. It would be nice if all these lines could be somehow combined or reduced, as my explain plans are now regularly approaching 1000 lines, and the usefulness to me of all but the first Bitmap Index Scan entry is limited. Second, I wanted to compare the efficiency of bitmaps directly, by running the same query with bitmapscan on and off, but when I set it to off it ends up taking a very long time indeed, and is not the same as running the query in a pre-bitmap (e.g. 8.0) environment. This probably cannot be fixed but it does make the speed comparisons a little more tricky as I have to end up comparing 8.0 queries with 8.1 queries, instead of 8.1 vs 8.1. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200505211624 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFCj5mdvJuQZxSWSsgRAmfoAKD2CkXDVM5RQWuHaGcFAjy/KjaoZwCfcaOD bgI5mcI12VtU8gPZWSLZ99A= =XidF -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] inet increment w/ int8
Patrick Welche wrote: On Fri, May 20, 2005 at 11:12:54PM -0400, Bruce Momjian wrote: Added to TODO: * Allow INET + INT4/INT8 to increment the host part of the address, or throw an error on overflow I have not heard any use-case for adding to the network value if INET, and by not using it, we can have an easy operator API. Thanks - I'll look at the code that was posted.. I modified the TODO. I think we only need an INT4. I realize INT8 would be for IPV6 but I can't imagine a network that has more than INT4 hosts (not part of the network address). -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
