Re: [HACKERS] Anyone want to assist with the translation of the
Justin wrote: Hi Michael, Michael Paesold wrote: snip Hi Justin, I am from Austria, and I would like to help. I could provide a German translation. The Babelfish's translation is really funny. Machine translation is readable, but it is no advocacy. ;-) I do not really nead an interface, but just tell me in what way you want the texts. Cool. Could you deal with an OpenOffice Calc or M$ Excel file having the lines of English text in one column, and doing the German translation into a second column? Isn't this, um, the sort of thing you might want to put into, um, a, um, database? -- (concatenate 'string aa454 @freenet.carleton.ca) http://cbbrowne.com/info/internet.html you can obvioulsy understand what i'm saying. you're just being pendantic. -- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Hot Backup
The world rejoiced as [EMAIL PROTECTED] (Andrew Sullivan) wrote: Having undertaken the exercise, I really can say that it is a little strange to think about what would happen to data I am in charge of in case a fairly large US centre were completely blown off the map. But with a little careful planning, you actually _can_ think about that, and provide strong assurances that things won't get lost. But it doesn't pay to call such questions silly, because they are questions that people will demand answers to before they entrust you with their millions of dollars of data. I was associated with one data center that has the whole barbed-wire-fences, 40-foot-underground-bunker, retina-scanning thing; they apparently /did/ do analysis based on the site being a potential target for nuclear attack. Realistically, two scenarios are much more realistic: a) The site resides in a significant tornado zone where towns occasionally get scraped off the map; b) The site isn't far from a small but busy airport, and they did consciously consider the possibility of aircraft crashing into the building. Presumably by accident, not by design; the company owns quite a number of jet aircraft, so that vulnerabilities involving misuse of aircraft would rapidly fly to mind... (Painfully and vastly moreso since 9/11, of course :-(.) When doing risk analysis, it is certainly necessary to consider these sorts of (admittedly paranoid) scenarios. It's a bit fun, in a way; you get to look for some pretty odd-ball situations; the server room being overrun by Mongol Hordes. That particular one isn't too likely, of course :-). -- (reverse (concatenate 'string moc.enworbbc@ sirhc)) http://www.ntlug.org/~cbbrowne/advocacy.html I've discovered that P=NP, but the proof is too long to fit within the confines of this signature... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC1?
On Wed, 13 Nov 2002 10:06:15 EST, the world broke into rejoicing as Tom Lane [EMAIL PROTECTED] said: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Why use awk for this at all ? and not: echo \\set ECHO all I think Bruce is worried about portability; some versions of echo might do something weird with the backslash. OTOH, it's not obvious to me that awk is better on that score. Bruce? The problem is that the regress script isn't pointing to the version of awk that was picked up in the autoconf phase. (More detailed comments forwarded directly :-).) The real deal on what happens on Solaris is thus, from the awk FAQ, where Patrick McPhee writes: SunOS includes three versions of awk. /usr/bin/awk is the old (pre-1989) version. /usr/bin/nawk is the new awk which appeared in 1989, and /usr/xpg4/bin/awk is supposed to conform to the single unix specification. No one knows why Sun continues to ship old awk. I would be /very/ inclined to trust Patrick's wisdom on this. So long as we fix up the regression script to grab the nawk that we expect to work, that's probably nicer than figuring out which echo parameters are needed... -- (concatenate 'string cbbrowne @ntlug.org) http://cbbrowne.com/info/wp.html The first cup of coffee recapitulates phylogeny. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone?
I've looked long and hard and can't find any license issues. Does anyone know of any that I may have missed? As far as I can see, as long as I maintain GPL restrictions, I should be fine. PostgreSQL isn't licensed under the GPL, so it sounds to me as though you're confused about the licensing issues. -- (concatenate 'string cbbrowne @cbbrowne.com) http://www3.sympatico.ca/cbbrowne/lsf.html My mom said she learned how to swim. Someone took her out in the lake and threw her off the boat. That's how she learned how to swim. I said, 'Mom, they weren't trying to teach you how to swim.' -- Paula Poundstone ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Ummm...I disagree. Lack of marketing is one of Postgres's major problems. Particularly when you compare against similar efforts from MySQL, Oracle, etc. Yes, indeed. The _prime_ reason for the fact that MySQL is the M in LAMP is that there is a steady, intent set of efforts going into marketing the M. People think that MySQL is faster, easier to use and more standard than its alternatives, and that is certainly the result of marketing. The /real/ technical merit of MySQL has been that there are some integrated tools for ISPs like CPANEL that make it easy for ISPs that don't know /anything/ about DBMSes to provide MySQL for their customers. CPANEL doesn't support PostgreSQL, and historically, it has been somewhat more difficult to support large numbers of PostgreSQL instances on a web server. Some of that has changed, though CPANEL /still/ doesn't support PostgreSQL. If any of you consider these technical issues to be small and petty, I'm afraid I don't /care/. More importantly, the hundreds of ISPs licensing CPANEL don't care. /They/ are the ones that would need convincing, and I don't think there's any real route to convince them that they should be pounding down CPANEL's door asking for a PostgreSQL front end and to convince them that they have to tell their customers: We sold you MySQL, telling you it was good for you to use. We were wrong, and our new story is that you should convert your databases over to use PostgreSQL. Anyone consider that a likely scenario? Anyone? It's fair to say that PostgreSQL doesn't need the likes of the Database HOWTO that gives a sales job that's so blindly enthusiastic as to be, well, blind. But an organization that has /no/ marketing department is at a severe disadvantage, like it or not. It is unfortunate that it is almost impossible to have a marketing group without there being some wilful blinders involved; it's vital for there to be some technical involvement in the marketing group to pop whatever bubbles they grow that are woefully wrong. But even if it operates with some occasional lack of /real/ vision, it's necessary to have a marketing group... -- (reverse (concatenate 'string moc.enworbbc@ sirhc)) http://cbbrowne.com/info/advocacy.html Rules of the Evil Overlord #106. If my supreme command center comes under attack, I will immediately flee to safety in my prepared escape pod and direct the defenses from there. I will not wait until the troops break into my inner sanctum to attempt this. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Kevin Brown wrote: Devrim G?ND?Z wrote: I do NOT like hearing about MySQL in this (these) list(s). PostgreSQL is not in the same category with MySQL. MySQL is for *dummies*, not database admins. I do not even call it a database. I have never forgotten my data loss 2,5 years ago; when I used MySQL for just 2 months!!! I think you're on to something here, but it's obscured by the way you said it. There's no question in my mind that PostgreSQL is superior in almost every way to MySQL. For those of us who are technically minded, it boggles the mind that people would choose MySQL over PostgreSQL. Yet they do. And it's important to understand why. Simply saying MySQL has better marketing isn't enough. It's too simple an answer and obscures some issues that should probably be addressed. I think it /is/ a significant factor, the point being that the MySQL company has been quite activist in pressing MySQL as the answer, to the point to which there's a development strategy called LAMP (Linux + Apache + MySQL + (Perl|Python|PHP)). People use MySQL because it's very easy to set up, relatively easy to maintain (when something doesn't go wrong, that is), is very well documented and supported, and is initially adequate for the task they have in mind (that the task may change significantly such that MySQL is no longer adequate is something only those with experience will consider). ... And the consistent marketing pressure that in essence claims: - It's easier to use than any alternative; - It's much faster than any other DBMS; - It's plenty powerful and robust enough. As near as I can tell, /none/ of these things are true outside of very carefully selected application domains. But the claims have been presented enough times that people actually believe them to be true. PostgreSQL has come a long way and, with the exception of a few minor things (the need to VACUUM, for instance. The current version makes the VACUUM requirement almost a non-issue as regards performance and availability, but it really should be something that the database takes care of itself), is equivalent to MySQL in the above things except for documentation and support. I would point to a third thing: Tools to support hands-off administration. My web hosting provider has a set of tools to let me administer various aspects of my site complete with pretty GUI that covers: - Configuring email accounts, including mailing lists, Spam Assassin, and such; - Configuring subdomains; - Managing files/directories, doing backups; - Apache configuration; - Cron jobs; - A couple of shopping cart systems; - A chat room system; - Last, but certainly not least, the ability to manage MySQL databases. There is no canned equivalent for PostgreSQL, which means that ISPs that don't have people with DBMS expertise will be inclined to prefer MySQL. It's a better choice for them. MySQL's documentation is very, very good. My experience with it is that it's possible, and relatively easy, to find information about almost anything you might need to know. PostgreSQL's documentation is good, but not quite as good as MySQL's. It's not quite as complete. For instance, I didn't find any documentation at all in the User's Guide or Administrator's Guide on creating tables (if I missed it, then that might illustrate that the documentation needs to be organized slightly differently). I did find a little in the tutorial (about the amount that you'd want in a tutorial), but to find out more I had to go to the SQL statement reference (in my case I was looking for the means by which one could create a constraint on a column during table creation time). The reason this is important is that the documentation is *the* way people are going to learn the database. If it's too sparse or too disorganized, people who don't have a lot of time to spend searching through the documentation for something may well decide that a different product (such as MySQL) would suit their needs better. The documentation for PostgreSQL improves all the time, largely in response to comments such as this one, and that's a very good thing. My purpose in bringing this up is to show you what PostgreSQL is up against in terms of widespread adoption. That's probably pretty fair. I'm using the word fair advisedly, too. If someone objects, saying that PostgreSQL docs /are/ good, keep in mind that new users are not mandated to be fair about this. If they have trouble finding what they were looking for, they couldn't care less that you think the docs are pretty good: /they/ didn't find what /they/ were looking for, and that's all they care about. If we want to sell PostgreSQL, we should talk about, maybe, Oracle. I have never took care of MySQL said. I just know that I'm running PostgreSQL since 2,5 years and I only stopped it JUST before upgrades of PostgreSQL. It's just *working*; which is unfamiliar
Re: [HACKERS] OS/400 support?
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Tom Lane) transmitted: Justin Clift [EMAIL PROTECTED] writes: We don't support OS/400 yet do we? Never heard of it. Is it Unix-y? Do you have one available for testing? No, OS/400 is what replaced IBM System 34, System 36, and System 38. (Apparently they jumped to 40, and then multiplied by 10 to suggest it was 10x as good...) It was based on the CMU Hydra project, which built an OS with a pretty strong security kernel, with ties to the orthogonal persistence notion. By this point, they have created a POSIX-emulation environment so it can pretend to be somewhat like a Unix, but underneath, it's a database system for running RPG code. As such, it kind of starts as a DBMS. Somehow, I'm not sure that PostgreSQL-on-OS/400 is likely to be more than a curiosity. -- (reverse (concatenate 'string moc.enworbbc@ enworbbc)) http://www3.sympatico.ca/cbbrowne/rdbms.html If you can't see the bright side of things, polish the dark side... ---(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: [HACKERS] psql and readline
On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as Bruce Momjian [EMAIL PROTECTED] said: Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. i.e. one up arrow get the previous \e, and a second up arrow would bring up the command that was worked upon. Makese sense. However, it still has the shock factor of displaying a huge query, which is usually what is involved when using the editor. I don't feel strongly either way --- I am just pointing out the issue. There's a surprise available in both directions. If the previous command was use external editor on query, then it seems unreasonable to forcibly expand that out. If I edited the query, it's more than likely that I'd like to edit it again. But I'd like to have a way to expand the query so that I /can/ see it in full form. It would be unfortunate for the /only/ way to get at the query would be to \e it. Perhaps the answer is to have some form of \expand directive that replaces itself with the query's contents, or, better still, which doesn't actually /execute/ the query, but rather pulls in the query from outside and pushes it into the command line. The /next/ time you hit enter, the query will get executed. -- output = reverse(moc.enworbbc@ enworbbc) http://cbbrowne.com/info/linux.html Eagles may soar, free and proud, but weasels never get sucked into jet engines. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] clock sync
On Thu, 09 Jan 2003 08:39:33 CST, the world broke into rejoicing as John Liu [EMAIL PROTECTED] said: How do I know the clock on the machine you're running on will be set to the same time as the clock on the database? how postgre handle this internal? You'll know because you already run NTP on all your servers to make sure that they are synchronizing times, right? PostgreSQL doesn't include time synchronization software because NTP does that perfectly well, just as it doesn't include a job scheduler because cron does that perfectly well. ... And if your machines have substantially different times, different sorts of issues will emerge depending on what you're doing. - If the client sends over literal current time stamps based on what time it thinks it is, that may differ from what time the server thinks it is. - If you do that, and then try looking in PostgreSQL logs, based on the client's timestamps, you'll look at the wrong times, and get confused. - If the client passes in things that select now(), timestamps will be returned based on when the /server/ thinks it is. Which should leave the database consistent, but which might confuse the client if it has logic that processes that time, and gets deranged because now() differs massively from what time it thinks it is. The case where you'll get /badly/ bitten is if you're trying to do replication with servers that have substantially differing ideas as to what time it is. But what you /should/ do is run NTP on all your machines, thus getting rid of the problem. http://www.ntp.org/ -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www3.sympatico.ca/cbbrowne/ntp.html Rules of the Evil Overlord #30. All bumbling conjurers, clumsy squires, no-talent bards, and cowardly thieves in the land will be preemptively put to death. My foes will surely give up and abandon their quest if they have no source of comic relief. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
Justin Clift wrote: For another perspective, we've been getting a few requests per day through the PostgreSQL Advocacy and Marketing site's request form along the lines of: Is there a license fee for using PostgreSQL? We'd like to distribute it with our XYZ product that needs a database. Probably about 4 or so per day like this at present. A lot of the people sending these emails appear to have windows based products that need a database, and have heard of PostgreSQL being a database that they don't need to pay license fee's for. They've kind of missed the point of Open Source from the purist point of view, but it's still working for them. ;-) If they are: a) not clueful enough to actually look at the license, and b) looking at it from the purely selfish perspective of not having to pay license fees, then are they /truly/ people where it is useful to put effort into being helpful? Furthermore, if their lawyers are incapable of reading the license and explaining to them You don't have to pay, I'd suggest the thought that maybe they have bigger problems than you can possibly solve for them. The great security quote of recent days is thus: If you spend more on coffee than on IT security, then you will be hacked. -- Richard Clarke The analagous thing might be: If you spend more on coffee than you do on getting proper legal advice about software licenses, then it's just possible that you might do something DOWNRIGHT STUPID and get yourself in a whole barrel of legal hot water. If these people are incapable of reading software licenses, and haven't any competent legal counsel to to do it for them, you've got to wonder if they are competent to sell licenses to their own software. I seriously doubt that they are. Furthermore, I'm not at all sure that it is wise for you to even /try/ to give them any guidance in this, beyond giving them a URL to the license, and saying Have your lawyer read this. If you start giving them interpretations of the license, that smacks of giving legal advice, and bar associations tend to frown on that. -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://cbbrowne.com/info/ Interfaces keep things tidy, but don't accelerate growth: functions do. -- Alan Perlis ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
Jeff Davis wrote: What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? It's been a while, but I know I've installed MySQL on windows without any separate step of installing Cygwin (I can't say 100% for sure that it didn't install some part of Cygwin transparently to me). That may have involved not being sufficiently observant, because the company quite clearly documents Cygwin as a dependancy. http://www.mysql.com/downloads/cygwin.html -- output = (aa454 @freenet.carleton.ca) http://www3.sympatico.ca/cbbrowne/linuxxian.html Change is inevitable, except from a vending machine. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
Jan Wieck wrote: Looking at the arguments so far, nearly everyone who questions the Win32 port must be vehemently against the Cygwin stuff anyway. So that camp should be happy to see it flushed down the toilet. And the pro-Win32 people want the native version because they are unhappy with the stepchild-Cygwin stuff too, so they won't care too much. What is interesting is that the MySQL folk don't seem to be vehemently against it, as a look at their downloads pages indicate that they depend on Cygwin for the Windows port of their product. -- output = (cbbrowne @ntlug.org) http://www.ntlug.org/~cbbrowne/lisp.html What did we agree about a leader?? We agreed we wouldn't have one. Good. Now shut up and do as I say... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
Jan Wieck [EMAIL PROTECTED] writes: Assuming all your assumptions are right, why the hell is Oracle's and MS SQL-Server's reputation that bloody good? They have marketing departments. ... As well as sizable systems integration departments devoted to the platforms in question. PostgreSQL doesn't have the latter, although the recent efforts make a move towards it. And what about MySQL? What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? http://www.mysql.com/downloads/mysql-3.23.html Windows downloads The Windows binaries use the Cygwin library. Source code for the version of Cygwin we have used is available on this page. http://www.mysql.com/downloads/cygwin.html -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://www.ntlug.org/~cbbrowne/spiritual.html When you have eliminated the impossible, whatever remains, however improbable, must be the truth. -- Sir Arthur Conan Doyle (1859-1930), English author. Sherlock Holmes, in The Sign of Four, ch. 6 (1889). [...but see the Holmesian Fallacy, due to Bob Frankston... http://www.frankston.com/public/Essays/Holmesian%20Fallacy.asp] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Case Studio II
Has anyone seriously tried out this package? It looks like a cheaper variant on ERWin, with the merit of having some PostgreSQL support. It only runs on WinTel, which is somewhat unfortunate, but I haven't gotten the sort of diagramming I have been looking for out of AutoDoc, so I'd be game to look at something pricey, assuming it is useful. -- http://cbbrowne.com/info/linux.html Rules of the Evil Overlord #50. My main computers will have their own special operating system that will be completely incompatible with standard IBM and Macintosh powerbooks. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] new procedural language - PL/R
Any strong feelings on whether this is necessary for a first release? No. I'm not sure you'd really need triggers written in R ever ;-) Yeah, that's what I figured too. Indeed. R sounds like it might be an interesting platform from which to do data mining, and in that sort of context, you're almost exclusively reading data, so the loss of triggers would be of no great importance. What might be nifty would be to have some mappings that did Clever Transformations of Queries Into Views, particularly if that allowed harnessing the DBMS to do some of the statistical analysis behind your back... -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www3.sympatico.ca/cbbrowne/rdbms.html After you've heard two eyewitness accounts of an auto accident it makes you wonder about history. -- Bits and Pieces ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Yet another open-source benchmark
OSDL has just come out with a set of open-source database benchmarks: http://www.osdl.org/projects/performance/ The bad news: This tool kit works with SAP DB open source database versions 7.3.0.23 or 7.3.0.25. (In fact, they seem to think they are testing kernel performance, not database performance, which strikes me as rather bizarre. But anyway.) That may be a terminology thing; the main SAP-DB process is called the kernel, and it's more than likely that the SAP-DB Kernel is the sense in which the term is being used. When they translate things from German, sometimes wordings change :-). -- output = reverse(moc.enworbbc@ enworbbc) http://www.ntlug.org/~cbbrowne/linuxxian.html Rules of the Evil Overlord #41. Once my power is secure, I will destroy all those pesky time-travel devices. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] XML ouput for psql
[EMAIL PROTECTED] writes: I don't agree with this: XML and XHTML are two different things. No one claimed anything to the contrary. We could certainly upgrade the HTML portion, but I am pretty sure that the XML standard calls for this format: columnnamedata here/columnname The XML standard does not call for any table format. But a number of table formats have been established within the XML framework. Some of them are formatting-oriented (e.g., the HTML model, or CALS which is used in DocBook) and some of them are processing-oriented (e.g., SQL/XML). Which do we need? And which do we need from psql in particular (keeping in mind that psql is primarily for interactive use and shell-scripting)? In any case, it should most likely be a standard table model and not a hand-crafted one. I would expect XML output to be based on whatever the tree of data contained. If the tree is to be rewritten, then this would mean having some sort of transformation engine in PostgreSQL that you would have to program. If I want a CALS table, then I'll push CALS table data into the database. If I'm storing a GnuCash chart of accounts in PostgreSQL, I am ludicrously uninterested in seeing it rewritten for some sort of physical layout. Spit out the tags that are stored in the database, not some rewriting of it. -- (reverse (concatenate 'string moc.enworbbc@ enworbbc)) http://cbbrowne.com/info/linuxdistributions.html (1) Sigs are preceded by the sigdashes line, ie \n-- \n (dash-dash-space). (2) Sigs contain at least the name and address of the sender in the first line. (3) Sigs are at most four lines and at most eighty characters per line. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] XML ouput for psql
Peter Eisentraut [EMAIL PROTECTED] writes:
I also think that psql is not the place to implement something like this.
Agreed.
It's most likely best put in the backend, as a function like
xmlfoo('select * from t1;')
That seems a little bizarre. Wouldn't we want to have a switch that
just flips the SELECT output format from one style to the other?
Ah, but this approach has the merit that it doesn't require pushing out
a completely new set of tools.
This is also a good time to stop and ask whether the frontend/backend
protocol needs to change to support this. Not having read the spec, I
have no idea what the low-level transport needs are for XML output,
but I suspect our present protocol is not it ...
That could be; there's enough variation in what one might want to do
with XML that it is not trivial to suggest an 'ideal' answer.
We have already seen the proposal of:
record a=b c=d e=f
record a=c c=e e=g
record a=d c=f e=h
record a=e c=g e=i
I would rather prefer something like:
tablea
record
ab/a cd/c ef/e
/record
record
ac/a cd/c ef/e
/record
record
ad/a cd/c ef/e
/record
tablea
(Note that both approaches are quite rational possibilities.)
I'd think that the protocol would involve passing back a row-as-string
for each row in the result set.
--
output = (cbbrowne @cbbrowne.com)
http://www.ntlug.org/~cbbrowne/xml.html
There are two major products that come out of Berkeley: LSD and Unix.
We don't believe this to be a coincidence. - Jeremy S. Anderson
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] make report
I'd like to implement *something* to help us collect information on what platforms actually have what features. This would be useful, for example, for figuring out whether any platforms are lacking 8 byte integers or are missing timezone infrastructure. I was thinking about something like make report which would mail the results of ./configure to, say, the ports mailing list. We could mention it in the text message printed at the end of the make cycle. Comments? Suggestions? Suggestion: Why not embed this information into the binary, and provide some way of extracting it. (There's a Linux kernel option that allows something similar, so it wouldn't be something unprecedented.) If all the config information is embedded in the binary, automatically, at compile time, then this allows the ability to be _certain_ that: - Oh, that was compiled with a really stupid set of compiler options; you'll have to recompile! - That was compiled without support for FOO, but with support for BAR. - Announcement, people: Look out for whether or not your distribution compiled PostgreSQL with proper support for 64 bit integers. Several distributions got this wrong with the 7.4.17 release, and you can see if it's OK by looking for LONG_LONG_REVISED in the embedded configuration information. [Downside: Announcement, script kiddies: If you find option UPDATE_DESCR_TABS=1 in the configuration information, then there's a very easy root exploit...] -- (reverse (concatenate 'string gro.gultn enworbbc)) http://www3.sympatico.ca/cbbrowne/x.html Rules of the Evil Overlord #176. I will add indelible dye to the moat. It won't stop anyone from swimming across, but even dim-witted guards should be able to figure out when someone has entered in this fashion. http://www.eviloverlord.com/ -- (concatenate 'string cbbrowne acm.org) http://www3.sympatico.ca/cbbrowne/spiritual.html Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail msg16196/pgp0.pgp Description: PGP signature
Re: [HACKERS] mV database tools
I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it possible to have arrays of arrays?) So it could be argued that PostgreSQL already provides part of what Arthur wants. It seems to me that there would be a whopping lot of value to the exercise of figuring out some way of layering MVD on top of a relational database, even if only to provide something sufficiently analytical to cope with the perpetual claims of: MultiValued Databases are Vastly, Spectacularly, the Bestest Kind of Database ever imagined in the universe! No, really they are! It might not be necessary to go all the way to fully layering such a thing atop PostgreSQL, although it would be a nice riposte to be able to respond with: Been there, done that. Of _COURSE_ PostgreSQL supports MultiValue. -- (reverse (concatenate 'string gro.gultn enworbbc)) http://www.cbbrowne.com/info/lisp.html Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail -- (reverse (concatenate 'string ac.notelrac.teneerf 454aa)) http://www.cbbrowne.com/info/spreadsheets.html Starting a project in C/C++ is a premature optimization. -- Peter Jensen msg16544/pgp0.pgp Description: PGP signature
Re: [HACKERS] PostgreSQL mission statement?
mlw [EMAIL PROTECTED] writes: Just out of curiosity, does PostgreSQL have a mission statement? Nope. Given the wide variety of views among the developer community, I think we'd have a tough time agreeing on a mission statement, unless it was so generic as to be meaningless ... Well, I think one of the things that has been agreed on that _isn't_ that generic is: We use a Berkeley style license, and prefer it that way. :-) -- (concatenate 'string cbbrowne @ntlug.org) http://www.ntlug.org/~cbbrowne/rdbms.html To err is human, to moo bovine. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Musings
On Mon, 06 May 2002 00:50:25 +1000, the world broke into rejoicing as Gavin Sherry [EMAIL PROTECTED] said: On Sun, 5 May 2002 [EMAIL PROTECTED] wrote: On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as mlw [EMAIL PROTECTED] said: It is sunday morning and I have been musing about some PostgreSQL issues. As some of you are aware, my dot com, dot died, and I am working on a business plan for a consulting company which, amongst other things, will feature PostgreSQL. As I am working on the various aspects, some issue pop up about PostgreSQL. Please don't take any of these personally, they are only my observations, if you say they are non issues I would rather just accept that we disagree than get into a nasty fight. They *are* issues to a corporate acceptance, I have been challenged by IT people about them. (1) Major version upgrade. This is a hard one, having to dump out and restore a database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a hard sell. If a customer has a very large database, this represents a large amount of down-time. If they are running on an operating system with file-size limitations it is not an easy task. It also means that they have to have additional storage which amount to at least a copy of the whole database. All of these things are true, and what you should throw back at the IT people is the question: So what do you do when you upgrade from Oracle 7 to Oracle 8? How about the process of doing major Informix upgrades? Sybase? Does it not involve some appreciable amounts of down-time? This is most definately the wrong way of thinking about this. I'm not saying that Mark sets a simple task, but the goals of Postgres should never be limited to the other products out there. Apparently you decided to fire back an email before bothering to read the paragraph that followed, which read: There may well be possible improvements to the PostgreSQL upgrade process; zero-downtime, zero-extra space upgrades do not seem likely to be amongst those things. Yes, there may well be improvements possible. I'd think it unlikely that they'd emerge today or tomorrow, and I think it's silly to assume that all responses must necessarily be of a technical nature. IT guys that are firing shots to the effect of We expect zero time upgrades are more than likely playing some other agenda than merely we'd like instant upgrades. For them to expect instant upgrades when _much_ more expensive systems offer nothing of the sort suggests to me that the _true_ agenda has nothing to do with upgrade time, and everything to do with FUD. If that's the case, and I expect FUD is in play in this sort of situation, then the purely technical response of we might try that someday is a Dead Loss of an answer. If they refuse to move from Oracle to PostgreSQL because PostgreSQL has no instant transparent upgrade scheme as compared to Oracle, which _also_ has no instant transparent upgrade, then do you realistically think that the lack of a instant transparent upgrade has ANYTHING to do with the choice? I'm merely suggesting that suitable questions head back to determine if the question is an honest one, or if it's merely FUD. -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://www.cbbrowne.com/info/lisp.html When man stands on toilet, man is high on pot. -Confucius ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] How much work is a native Windows application?
I think, and I know people are probably sick of me spouting opinions, that if you want a Windows presence for PostgreSQL, then we should write a real Win32 version. The crucial wrong word is the word we. If _you_ want a Windows presence, then _you_ should write a real Win32 version. That clearly attaches responsibility to someone who is interested. -- (reverse (concatenate 'string gro.mca@ enworbbc)) http://www.cbbrowne.com/info/unix.html I'm not switching from slrn. I'm quite confident that anything that *needs* to be posted in HTML is fatuous garbage not worth my time. -- David M. Cook [EMAIL PROTECTED] -- (reverse (concatenate 'string moc.enworbbc@ enworbbc)) http://www.ntlug.org/~cbbrowne/spreadsheets.html Rules of the Evil Overlord #166. If the rebels manage to trick me, I will make a note of what they did so that I do not keep falling for the same trick over and over again. http://www.eviloverlord.com/ msg16822/pgp0.pgp Description: PGP signature
Re: [HACKERS] How much work is a native Windows application?
[EMAIL PROTECTED] wrote: I think, and I know people are probably sick of me spouting opinions, that if you want a Windows presence for PostgreSQL, then we should write a real Win32 version. The crucial wrong word is the word we. If _you_ want a Windows presence, then _you_ should write a real Win32 version. That clearly attaches responsibility to someone who is interested. I have already said that I am willing to write the pieces for a Windows port. The issue is changes in PostgreSQL required to do it. No, I don't think you understand. If you're planning to do a port, then _all_ changes are your responsibility. Nobody ought to need to change PostgreSQL in order for you to write a Windows port; that, in fact, would be a waste of time, having several people working on something that should probably be done by one person. -- (concatenate 'string aa454 @freenet.carleton.ca) http://www.ntlug.org/~cbbrowne/x.html Why are they called apartments, when they're all stuck together? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Monitoring backend activities
Hi everybody, I'm a hookie in this discussion list. Well, my intent is to get some informations about PostgreSQL internals to work on a project. There is an excellent GPL'ed tool to work with Oracle called TOra. It is as good as TOAD and SQL Navigator from Quest Software. As a meaning of collaborate with the Open Source world i was thinking in port TOra to PostgreSQL. So, we'll have a great database and a great tool to manage it. I think that would be rookie; the term hookie refers to what you're playing if you skip school. Problem is: reading PostgreSQL documentation i didn't find any information about system tables having runtime informations as Oracle has. And one of the great features of TOra is the possibility to see in charts, in real-time, all kind of I/O operations, memory usage, queries being executed, etc... The only problem I see is that TOra already seems quite well supported for PostgreSQL. I'm running it at the moment, and it works quite well... -- (concatenate 'string cbbrowne cbbrowne.com) http://www.cbbrowne.com/info/lsf.html Put simply, the antitrust laws in this country are basically a joke, protecting us just enough to not have to re-name our park service the Phillip Morris National Park Service. -- Courtney Love, Salon.com, June 14, 2000 -- (concatenate 'string cbbrowne ntlug.org) http://www.cbbrowne.com/info/rdbms.html Rules of the Evil Overlord #220. Whatever my one vulnerability is, I will fake a different one. For example, ordering all mirrors removed from the palace, screaming and flinching whenever someone accidentally holds up a mirror, etc. In the climax when the hero whips out a mirror and thrusts it at my face, my reaction will be ``Hmm...I think I need a shave.'' http://www.eviloverlord.com/ -- (reverse (concatenate 'string moc.enworbbc sirhc)) http://www.cbbrowne.com/info/linuxxian.html As of next Monday, MACLISP will no longer support list structure. Please downgrade your programs. msg16907/pgp0.pgp Description: PGP signature
Re: [HACKERS] Native Win32, How about this?
A binary version of PostgreSQL for Windows should not use the cygwin dll. I know and understand there is some disagreement with this position, but in this I'm sure about this. That may ultimately be desirable. In the short term, it is likely preferable to use cygwin. It is only necessary to point at MySQL for an example. Cygwin is used there. http://www.mysql.com/downloads/mysql-3.23.html It is being used widely, crap or not. Cygwin may not ultimately be the ideal thing to use; we don't yet live in Pangloss' Best of All Possible Worlds, and thus have to live with some things not being ideal. If having the installer install Cygwin as well as the DBMS makes it easy to have something usable soon, and this allows 100,000 WinFolk to try out PostgreSQL, then that's a Big Win. Out of 100K users, surely two or three may be attracted into working on a more Panglossian solution. It may be fair to say that none of those 100K folk would be using PostgreSQL to support HA applications involving hundreds of GB of data. That's _fine_. If there are new 100K folk using PostgreSQL/cygwin, _some_ of them will outgrow its capabilities, and come looking for improvements. And as they're Windows users, accustomed to having to pay hefty amounts to Microsoft to get support no better than that provided by the Psychic Friends Network (see http://www.bmug.org/news/articles/MSvsPF.html), they'll doubtless be prepared to have to pay _something_ in order for PostgreSQL/Win3K-Enterprise Edition to become available. That seems a not too unreasonable path towards the Best of All Possible Worlds. There may be a bit of hyperbole in the above, but any time Voltaire gets quoted, that's likely to happen :-). -- (reverse (concatenate 'string gro.gultn enworbbc)) http://www.cbbrowne.com/info/wp.html Eagles may soar, but weasels don't get sucked into jet engines. -- (concatenate 'string cbbrowne ntlug.org) http://www.cbbrowne.com/info/multiplexor.html It's a little known fact that the Dark Ages were caused by the Y1K problem. msg16930/pgp0.pgp Description: PGP signature
Re: [HACKERS] Redhat 7.3 time manipulation bug
--=-Z1lifK4QZqKV8kHqHfYT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-05-22 at 10:51, Lamar Owen wrote: What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2= .5=20 (same as Red Hat 7.3's version). This is a completely different version. Once Debian updates (in a few years) they'll get the same result. If you are misusing interfaces you get what you deserve. At no time was it correct to use these functions for general date manipulation. It always only was allowed to use them to represent system times and there was no Unix system before the epoch. Therefore you argumentation is completely wrong. If you need date manipulation write your own code which work for all the times you want to represent. This is indeed a problem with dates on LIBC, because even if it is theoretically satisfactory to describe dates within some range within 2^31 seconds of 1970, that is certainly NOT satisfactory for describing all dates of interest unless you're being terribly parochial about what is to be considered of interest. My father's birth falls within 2^31 seconds of 1970, but the Battle of Agincourt doesn't. Any backup of any Unix system in history falls within 2^31 seconds of 1970, but there are people alive whose births don't. People get away with using Unix dates as a general date type when they don't have to work outside a limited range. If/when there is a move to 64 bit values, that will provide something with enough range to cover history back to ridiculously early times, relieving the limit. But anybody using Unix dates as general dates has leaped into exactly the same sort of trap that caused people to get so paranoid about Y2K. -- (concatenate 'string cbbrowne @acm.org) http://www.cbbrowne.com/info/oses.html Do Roman paramedics refer to IV's as 4's? -- (concatenate 'string aa454 @freenet.carleton.ca) http://www.ntlug.org/~cbbrowne/linuxxian.html So, when you typed in the date, it exploded into a sheet of blue flame and burned the entire admin wing to the ground? Yes, that's a known bug. We'll be fixing it in the next release. Until then, try not to use European date format, and keep an extinguisher handy. -- [EMAIL PROTECTED] (Tequila Rapide) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Redhat 7.3 time manipulation bug
On 22 May 2002, Ulrich Drepper wrote: On Wed, 2002-05-22 at 11:23, Tom Lane wrote: Unix systems have *always* interpreted time_t as a signed offset from the epoch. No. This always was an accident if it happens. Do you really think that when Unixen were first built in the early 70s, there was no interest in working with pre-1970 dates? Hardly likely. There never were files or any system events with these dates. Yes. And just to educate you and your likes: the majority of systems on this planet use mktime this way. I hate using this as an argument, but beside major Unixes M$ systems also do this. M$ systems crashes regularly too ... is Redhat going to adopt that too? Harbison and Steele indicates that: Although the traditional return type of time is long, the value returned is usually of type unsigned long. That is NOT a Linux reference; it was published before Linus had started working on his kernel project. ANSI does not indicate that time_t is a signed int, signed long, or whatever. It is only defined to be an arithmetic type. It would not be a bug for GLIBC to define time_t to be an unsigned int, with an epoch beginning of January 1, 1999. That definition would conform to ANSI C. Since that definition can conform to ANSI C, and Unix systems have more particularly been known to use unsigned ints with epoch of 1970, it is NOT reasonable to assume that time_t can be used to express dates that are at all ancient in the past. Indeed, it is fairly _useful_ for different libc implementations to make different assumptions about things whose definitions are permitted to vary, as this makes it easier to call out as WRONG those systems that make up their own definitions. People will no doubt get defensive about their own non-standard implementations of things; it is certainly far easier to cry They're trying to play Microsoft! than it is to be honest and actually look at the standards. -- (concatenate 'string cbbrowne ntlug.org) http://www.cbbrowne.com/info/advocacy.html When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- (reverse (concatenate 'string gro.mca enworbbc)) http://www.cbbrowne.com/info/linuxxian.html As of next Monday, COMSAT will be flushed in favor of a string and two tin cans. Please update your software. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Redhat 7.3 time manipulation bug
On Fri, 24 May 2002 06:10:39 PDT, the world broke into rejoicing as Thomas Lockhart [EMAIL PROTECTED] said: ... But anybody using Unix dates as general dates has leaped into exactly the same sort of trap that caused people to get so paranoid about Y2K. Certainly true. We don't use Unix dates as general dates, we use the Unix time zone database and API for dates and times within the year range of 1903 to 2038. Well, up until now anyway... I don't think going past 1970 is particularly safe; it certainly doesn't seem to fit with ANSI... By the way, the seemingly relevant link to look at for TZ info is http://www.twinsun.com/tz/tz-link.htm, linking to the data used by various Unix implementations. Prior to the 1900s, the concept of time zones was more localized and not universally adopted. In the US, a first round of time zone standardization came with the transcontinental railroads in the 1860s. After 2038, it is a good bet that time zones will resemble those in use today, but they are as much a political construct as a physical one so the details are subject to change. Some of the zones are quite peculiar if you head to Africa and Asia; there are some sitting on 15 minute intervales, rather than the usual 1h intervals. (The classic Canadian timezone joke is World ends at 9:00; 9:30 in Newfoundland. For more information, see TZ='America/St_Johns') -- (concatenate 'string chris @cbbrowne.com) http://www.ntlug.org/~cbbrowne/spreadsheets.html Heuristics (from the French heure, hour) limit the amount of time spent executing something. [When using heuristics] it shouldn't take longer than an hour to do something. ---(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: [HACKERS] Redhat 7.3 time manipulation bug
The last phase could be extending the API to allow multiple simultaneous time zones, detection of bad time zones, etc etc. This would involve API changes or extensions, and breaks compatibility with system-supplied infrastructure. One thing that wasn't clear to me, but could use investigation: if so many systems are using the same underlying timezone database info, maybe there is some commonality at a level below the ISO mktime/tzset/etc API. If we could make use of the system-provided TZ database at a lower level while still using our own APIs not tied to time_t, it'd answer the issue of compatibility with the surrounding system. (Which is a real issue, I agree --- we should be able to accept the system's standard TZ setting if possible.) The fundamental problem (which of course can have a fundamental solution ;) is that a time zone database built with a 32-bit time_t will have time zone info through 2038 only (it is a binary file with 32-bit time fields -- almost certainly anyway). So if we have an extended time zone infrastructure using something different for time_t we would need to handle the case of reading non-extended time zones databases, which puts us back to having limitations. Ah, but the database in question _doesn't_ consist of 32 bit time_t values. It consists of things like: # @(#)zone.tab 1.26 # # TZ zone descriptions # # From Paul Eggert [EMAIL PROTECTED] (1996-08-05): # # This file contains a table with the following columns: # 1. ISO 3166 2-character country code. See the file `iso3166.tab'. # 2. Latitude and longitude of the zone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS, # first latitude (+ is north), then longitude (+ is east). # 3. Zone name used in value of TZ environment variable. # 4. Comments; present if and only if the country has multiple rows. # # Columns are separated by a single tab. # The table is sorted first by country, then an order within the country that # (1) makes some geographical sense, and # (2) puts the most populous zones first, where that does not contradict (1). # # Lines beginning with `#' are comments. # #country- #code coordinates TZ comments AD +4230+00131 Europe/Andorra AE +2518+05518 Asia/Dubai AF +3431+06912 Asia/Kabul AG +1703-06148 America/Antigua AI +1812-06304 America/Anguilla AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan AN +1211-06900 America/Curacao AO -0848+01314 Africa/Luanda Then a leapseconds table, looking like: # The correction (+ or -) is made at the given time, so lines # will typically look like: # LeapYEARMON DAY 23:59:60+ R/S # or # LeapYEARMON DAY 23:59:59- R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is UTC # Leap YEARMONTH DAY HH:MM:SSCORRR/S Leap1972Jun 30 23:59:60+ S Leap1972Dec 31 23:59:60+ S Leap1973Dec 31 23:59:60+ S Leap1974Dec 31 23:59:60+ S Leap1975Dec 31 23:59:60+ S Leap1976Dec 31 23:59:60+ S And then a set of rules about timezone adjustments for all sorts of localities, including the following: # Rule NAMEFROMTO TYPEIN ON AT SAVELETTER/S # Summer Time Act, 1916 RuleGB-Eire 1916only- May 21 2:00s 1:00BST RuleGB-Eire 1916only- Oct 1 2:00s 0 GMT # S.R.O. 1917, No. 358 RuleGB-Eire 1917only- Apr 8 2:00s 1:00BST RuleGB-Eire 1917only- Sep 17 2:00s 0 GMT # Zone NAMEGMTOFF RULES FORMAT [UNTIL] Zone Antarctica/Casey 0 - zzz 1969 8:00- WST # Western (Aus) Standard Time Zone Antarctica/Davis 0 - zzz 1957 Jan 13 7:00- DAVT1964 Nov # Davis Time 0 - zzz 1969 Feb 7:00- DAVT Zone Antarctica/Mawson 0 - zzz 1954 Feb 13 6:00- MAWT# Mawson Time I'm guessing that a better approach might be to have our time zone stuff inside our own API, which then could choose to call, for example, mktime() or pg_mktime(), which could each have different signatures. Then the heuristics for matching one to the other are isolated to our thin API implementation, not to the underlying system- or pg-provided libraries. matching stringy time zones to numeric offsets for input date/times. The time zone databases themselves
Re: [HACKERS] Alternatives to SQL ...
The world rejoiced as [EMAIL PROTECTED] (Martijn van Oosterhout) wrote: On Fri, May 24, 2002 at 12:43:36PM -0500, Gunther Schadow wrote: - Sending a parse tree in XML for processing by the optimizer. This circumvents the SQL language and avoids the kinds of syntactic ideosyncrasies of SQL (e.g., where you put commas.) This is fairly trivial, but of course the question is, would it be worth it? X-Mailer: mh-e 6.1; nmh 1.0.4+dev; Emacs 21.4 I don't know if you can design something in XML that is expressive and simple enough to compete with SQL. SQL is a simple language, why replace it with something unless it is demonstrably better. SQL is good at providing linear queries; queries that indicate some linear relationship between elements. It is not so good at representing hierarchical relationships, which is what XML is about. The SQL: SELECT FIELDS FROM TABLE provides you with a linear list. SQL isn't _nearly_ as nice at representing things that are naturally expressed as trees. It's pretty easy to have a DB schema where you essentially have to submit an SQL query for every level of the tree. And I am not ignoring JOIN here; that adds _some_ ability to join together levels of trees, but not an unlimited ability. The XML model fundamentally involves a hierarchy, and the 'query method' involves passing in a function that reshapes that hierarchy. I think there would be considerable value to that. It certainly needs to be thought about before it is implemented, but it's worth thinking about, to be sure. -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://www.ntlug.org/~cbbrowne/multiplexor.html It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. -- RFC 1925 ---(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: [HACKERS] A fairly obvious optimization?
On Sun, 23 Jun 2002 17:16:09 EDT, the world broke into rejoicing as Bruce Momjian [EMAIL PROTECTED] said: FAQ updated in section 4.8: My queries are slow or don't make use of the indexes. Why? is returned. In fact, though MAX() and MIN() don't use indexes, it is possible to retrieve such values using an index with ORDER BY and LIMIT: PRE SELECT col FROM tab ORDER BY col LIMIT 1 /PRE This sounds like the sort of thing that would be really nice to be able to automate into the query optimizer... -- (reverse (concatenate 'string moc.enworbbc@ sirhc)) http://www3.sympatico.ca/cbbrowne/spreadsheets.html I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science. -- D. E. Knuth ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgres idea list
On Wed, 26 Jun 2002 11:35:07 PDT, the world broke into rejoicing as Josh Berkus [EMAIL PROTECTED] said: What do you see as the drawbacks with java, and how can they be circumvented? 1. Java is not Open Source. It's an open standard, but not OS. The problem is not with the language; it is with the layered libraries on top. It's reasonably usable as a server side language; the _real_ serious problems come in if you want to build a GUIed application, when your choice is between: a) A really klunky AWT UI that will be unacceptable to all, and b) A SWING UI that makes your application critically dependent on non-open source software. The old Java 1.01 stuff is fairly successfully freely usable, but that's not what anyone wants to develop with. They want the cool new J2EE stuff, and it takes some serious research to figure out that you aren't going to be doing that with 'free software,' despite the existence of stuff like JBoss. You still need components that are Definitely Not Free. The answer is that someone has to implement a complete set of replacements for the SunSoft components under free licenses. That circumvention is a distinctly non-trivial task. 2. I understand that there are some serious limitations to the current Postgres JDBC drivers. I have not used them, so I'm reporting rumor, here. I've not run into problems with them, but maybe my use hasn't been extensive enough :-). -- (concatenate 'string cbbrowne @acm.org) http://cbbrowne.com/info/rdbms.html Remember folks. Street lights timed for 35 mph are also timed for 70 mph. -- Jim Samuels ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgres idea list
On 26 Jun 2002 14:36:15 EDT, the world broke into rejoicing as Dave Cramer [EMAIL PROTECTED] said: Josh, 1) There is an open source implementation of java 2) The jdbc driver is much better than it was recently we have made lots of improvements, and it won't affect jpgadmin anyway. I actually think writing the admin tool in java will make the driver better. 3) Don't see this as a big issue we aren't writing something esoteric here. There are free software implementations of Java compilers and of Java Virtual Machines. Are there suitable free software implementations of _all_ the libraries that you will be needing to construct the admin tool? In particular, can you direct us to a free software implementation of Swing? I doubt that you can, and _that_ is the characteristic problem with Java. The language is free enough, but the libraries you will want to use aren't... -- (concatenate 'string chris @cbbrowne.com) http://www3.sympatico.ca/cbbrowne/spreadsheets.html HAKMEM ITEM 163 (Sussman): To exchange two variables in LISP without using a third variable: (SETQ X (PROG2 0 Y (SETQ Y X))) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Just a long standing curiosity? For most web sites MySQL seems to work fine, but overall PostgreSQL offers more capabilites so why build upon a limited base such as MySQL? Does anyone here have any idea as to why so many people select MySQL when both systems are open sourced? Three likely effects: a) ISP management toolsets include management tools for MySQL, and not PostgreSQL. (CPanel is an example of such a toolset.) b) Apparently the permissions model for PostgreSQL used to discourage its use in shared hosting environments. (Ask Neil Conway more about this.) c) There was corporate sponsorship of MySQL, and they probably spent money marketing it in the ISP web hosting market. d) MySQL is GPL-licensed, and some people consider that very important. (And are too stupid to grasp that they like XFree86, which _isn't_ licensed under the GPL... Of course, this is d), and I said three likely effects...) e) Inertia. MySQL got more popular way back when; the reasons may no longer apply, but nobody is going to move to PostgreSQL without _compelling_ reason, and you'll have to show something _really compelling_. -- (concatenate 'string cbbrowne @acm.org) http://cbbrowne.com/info/advocacy.html FLORIDA: Where your vote counts and counts and counts. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Table inheritance versus views
On 29 Jul 2002 18:27:40 MDT, the world broke into rejoicing as Stephen Deasey [EMAIL PROTECTED] said: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. Table inheritance offers data model extensibility. New (derived) tables can be added to the system, and will work with existing code that operates on the base tables, without having to hack up all the code. But it kind of begs the question of why you're creating the new table in the first place. The new table certainly _won't_ work with existing code, at least from the perspective that the existing code doesn't _refer_ to that table. The same is not true for views; if you create a new view on a table, the existing code that refers to the table in either raw form or in other views already exist will certainly continue to work. Inherited indexes etc. would be nice, but it's the inability to have referential integrity against a base table that picks up child table rows that makes the current implementation useles. Views will certainly inherit indices, and continue to maintain referential integrity against the base table. I would rather see it fixed than junked, and better yet extended. It would be incredibly useful in real-world projects with complex data models like OpenACS. Have they found views to be an unacceptable alternative? I just don't see that there's _all_ that much about table inheritance that is really fundamentally wonderful. The incredibly useful thing, it seems to me, would be to provide tools that make it less necessary to create additional tables. To be sure, views do that. I'm not quite sure what INHERITS buys us that we don't get from SELECT * into new_table from old_table INHERITS may automagically draw in some contraints that have been specifically tied to old_table that wouldn't be drawn by SELECT * INTO NEW_TABLE; the latter _will_ inherit anything that is tied to the types. I'd _much_ rather have five views on one table than five tables. -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://cbbrowne.com/info/spreadsheets.html Everything should be made as simple as possible, but not simpler. -- Albert Einstein ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Third Manifesto
On Fri, 2002-08-02 at 08:55, Curt Sampson wrote: On Fri, 2 Aug 2002, Marc G. Fournier wrote: Isn't inheritance kinda one of those things that is required in order to be consider ourselves ORBDMS, which we do classify our selves as being? Well, it depends on what you call an ORDBMS. By the standards of Date and Darwen in _The Third Manifesto_, Is _The Third Manifesto_ available online ? The full book is not. An earlier version of the work is available as: http://www.acm.org/sigmod/recor d/issues/9503/manifesto.ps It's actually an easier read than the full book. -- (concatenate 'string cbbrowne cbbrowne.com) http://www3.sympatico.ca/cbbrowne/finances.html very few people approach me in real life and insist on proving they are drooling idiots. -- Erik Naggum, comp.lang.lisp ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Standard replication interface?
--=-QQHYShMlxI2BY71i6NiO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable As I said -- I don't really see the need for a bunch of replication implementations, and therefore I don't see the need for a generic API to make the whole mess (slightly) more manageable. I see. So the intension of the core developers is to have one and only one replication solution? If the various solutions may be folded down into a smaller set of programs, perhaps, ultimately, into _one_ program, that would surely be easier to manage, in the codebase, than having five or six such programs. If one program can do the job that needs to be done, and it has not been _clearly_ established that that is _not_ possible, then I'd think it rather silly to have a bunch of replication solutions that need to be updated any time a relevant change goes into the database engine. I'd be surprised if, in the end, there truly _needed_ to be more than about two approaches. Should the team plan to _have_ a mess? I'd think not. -- (concatenate 'string cbbrowne ntlug.org) http://cbbrowne.com/info/linuxdistributions.html We don't understand the software, and sometimes we don't understand the hardware, but we can *see* the blinking lights! -- Unknown ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Documentation DTD
Rod Taylor writes: Anyone mind if we bump the DTD version to Docbook 4.2? Not sure if we should do this now. We're approaching the time where people should be writing documentation, not having to refiddle their carefully crafted DocBook installations. We're not going to realize any immediate benefits anyway. Indeed. What it buys is a number of useful tags, SVGs and probably more importantly for the future, xsl and fop support which will probably be important in the future. OpenJade hasn't had a new release in quite a long time -- not to say work isn't needed. The last release was in January. Yes, after updating docs to the newer DTD I intend to make them XML compliant to ensure they work with v5 of docbook in the future. Ah, an XML vs. SGML debate. I look forward to it. Please no! If and when it becomes forcibly preferable to use XML, there's a tool called sgml2xml that is part of the sp package (which includes nsgmls and sgmlnorm) that does a Perfectly Good Job of this. Totally automated. Possible exception: sgml2xml capitalizes all the tags, and it looks like the XML DTD wants MixedCaseTagging, which is a rather irritating thing about XML; in any case, that's something that should be fixed up in one fell swoop in a normalize it all and make it into XML process LATER. It would make sense to fix use of any deprecated elements, but fixing any XML aspects of it now is pretty much a senseless exercise. -- (reverse (concatenate 'string moc.enworbbc enworbbc)) http://www.ntlug.org/~cbbrowne/emacs.html Computers in the future may weigh no more than 1.5 tons. -- POPULAR MECHANICS magazine forecasting the relentless march of science 1955 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] How To Make Things Appear More Dramatic
An alarmist style when posting a serious error is a good idea. Hey guys, I found a possible problem... Does not seem to generate the needed level of excitement. DOS attacks means that business stops. I think that should generate a furrowed brow, to say the least. Obviously people have forgotten past history. The Symbolics guys had _great_ techniques for this that were well documented: It is considered artful to append many messages on a subject, leaving only the most inflammatory lines from each, and reply to all in one swift blow. The choice of lines to support your argument can make or break your case. -- from the Symbolics Guidelines for Sending Mail % State opinions in the syntax of fact: ...as well as the bug in LMFS where you have to expunge directories to get rid of files. -- from the Symbolics Guidelines for Sending Mail % People can be set wondering by loading obscure personal patchable systems, and sending bug reports. Who would not stop and wonder upon seeing Experimental TD80-TAPE 1.17, MegaDeath 2.5...? The same for provocatively-named functions and variables in stack traces. -- from the Symbolics Guidelines for Sending Mail % Know the list of large, chronic problems. If there is any problem with the window system, blame it on the activity system. Any lack of user functionality should be attributed to the lack of a command processor. A suprisingly large number of people will believe that you have thought in depth about the issue to which you are alluding when you do. -- from the Symbolics Guidelines for Sending Mail % Know how to blow any problem up into insolubility. Know how to use the phrase The new ~A system to insult its argument, e.g., I guess this destructuring LET thing is fixed in the new Lisp system, or better yet, PROLOG. -- from the Symbolics Guidelines for Sending Mail % Never hit someone head on, always sideswipe. Never say, Foo's last patch was brain-damaged, but rather, While fixing the miscellaneous bugs in 243.xyz [foo's patch], I found -- from the Symbolics Guidelines for Sending Mail % Idiosyncratic indentations, double-spacing, capitalization, etc., while stamps of individuality, leave one an easy target for parody. -- from the Symbolics Guidelines for Sending Mail % Strong language gets results. The reloader is completely broken in 242 will open a lot more eyes than The reloader doesn't load files with intermixed spaces, asterisks, and 's in their names that are bigger than 64K. You can always say the latter in a later paragraph. -- from the Symbolics Guidelines for Sending Mail % Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail % When replying, it is often possible to cleverly edit the original message in such a way as to subtly alter its meaning or tone to your advantage while appearing that you are taking pains to preserve the author's intent. As a bonus, it will seem that your superior intellect is cutting through all the excess verbiage to the very heart of the matter. -- from the Symbolics Guidelines for Sending Mail % Referring to undocumented private communications allows one to claim virtually anything: we discussed this idea in our working group last year, and concluded that it was totally brain-damaged. -- from the Symbolics Guidelines for Sending Mail % Points are awarded for getting the last word in. Drawing the conversation out so long that the original message disappears due to being indented off the right hand edge of the screen is one way to do this. Another is to imply that anyone replying further is a hopeless cretin and is wasting everyone's valuable time. -- from the Symbolics Guidelines for Sending Mail % Keeping a secret Hall Of Flame file of people's mail indiscretions, or copying messages to private mailing lists for subsequent derision, is good fun and also a worthwhile investment in case you need to blackmail the senders later. -- from the Symbolics Guidelines for Sending Mail % Users should cultivate an ability to make the simplest molehill into a mountain by finding controversial interpretations of innocuous sounding statements that the sender never intended or imagined. -- from the Symbolics Guidelines for Sending Mail % Obversely, a lot of verbal mileage can also be gotten by sending out incomprehensible, cryptic, confusing or unintelligible messages, and then iteratively correcting the mistaken interpretations in the replys. -- from the Symbolics Guidelines for Sending Mail % Trivialize a user's bug report by pointing out that it was fixed independently long ago in a system that hasn't been released yet. -- from the Symbolics Guidelines for Sending Mail % Send messages calling for fonts not available to the recipient(s). This can (in the case of Zmail) totally disable the user's machine and mail system
Re: [HACKERS] HISTORY updated, 7.3 branded
Shridhar Daithankar dijo: On 4 Sep 2002 at 3:24, Bruce Momjian wrote: OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. Some minor stuff, In the schema changes description: Schemas allow users to create objects in their own namespace so two people can have the same table with the same name. Shouldn't it read so two people can have tables with the same name ? My point is that the tables are not the same, they just have the same name. How about this for a wording: Schemas allow users or applications to have their own namespaces in which to create objects. A typical application of this is to allow creation of tables that _appear_ to have the same name. For instance, if some GNOME applications were using PostgreSQL to store their configuration, a GNUMERIC namespace might have a table PREFERENCES to store preferences for that application, while a POWERSHELL namespace would allow _that_ application to store configuration in a PREFERENCES table that is quite distinct from the GNUMERIC one. The true table names may be GNUMERIC.PREFERENCES and POWERSHELL.PREFERENCES, but by using Schemas, applications do not need to be speckled with gratuitious added prefixes of GNUMERIC or POWERSHELL. Note that I'm pointing at applications as the primary purpose for this, as opposed to users. In the long run, are not applications more likely to be the driving force encouraging the use of schemas? -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://www3.sympatico.ca/cbbrowne/unix.html The most precisely-explained and voluminously-documented user interface rule can and will be shot to pieces with the introduction of a single new priority consideration. -- Michael Peck ---(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: [HACKERS] Inheritance
On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: Suppose you have a table CITIZEN with table-level constraint IS_GOOD which is defined as kills_not_others(CITIZEN). and there is table CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table MILITARY (...) UNDER CIVIL_SERVANT, where you have other criteria for IS_GOOD This I very much disagree with. In most object-oriented languages (Eiffel being a notable exception, IIRC), you can't specify constraints on objects. But in a relational database, you can specify constraints on tables, and it should *never* *ever* be possible to violate those constraints, or the constraints are pointless. That's not how real world (which data is supposed to model) operates ;) As Greg already pointed out, there are two kinds of constraints - database integrity constraints (foreign key, unique, not null, check), which should never be overridden and business-rule constraints which should be overridable in child tables. one can argue that the latter are not constraints at all, but they sure look like constraints to me ;) To elaborate on Gregs example if you have table GOODS and under it a table CAMPAIGN_GOODS then you may place a general overridable constraint valid_prices on GOODS which checks that you dont sell cheaper than you bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so you override the constraint for CAMPAIGN_GOODS. What that tells me is that the constraint, valid_prices, shouldn't have been on GOODS in the first place. If it is not a legitimate constraint for the children, then it is not a legitimate constraint for the parent. In human inheritance, if you marry someone with funny coloured skin, you don't get to choose that your children won't have funny coloured skin. That's a pretty forcible constraint. :-). For the GOODS situation, the constraint ought not to be on GOODS in the first place. There ought to be a table ORDINARY_GOODS, or some such thing, to which the constraint applies, and from which CAMPAIGN_GOODS will _not_ be inheriting. So if I have a constraint that says, no rows appearing in this table will ever violate constraint X, and then you go and create a way of inserting rows into that table that violate that constraint, I think you've just made the database into a non-relational database. SQL standard constraints should be non-overridable. I still think that Constraint triggers should be overridable/dynamic. Or maybe it is better to just make the check function should be dynamically dispatched, so the constraint will always hold, it just can mean different things for different types. Or maybe if someone is doing an Object Oriented design, and making extensive use of inheritance, they'll need to apply constraints in a manner that allow them to be properly inherited. -- (concatenate 'string aa454 @freenet.carleton.ca) http://cbbrowne.com/info/ If a cow laughed, would milk come out its nose? ---(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: [HACKERS] Inheritance
Oops! [EMAIL PROTECTED] (Greg Copeland) was seen spray-painting on a wall: --=-eu74lKXry3SVx8eZ/qBD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-09-06 at 08:57, [EMAIL PROTECTED] wrote: On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: To elaborate on Gregs example if you have table GOODS and under it a table CAMPAIGN_GOODS then you may place a general overridable constraint valid_prices on GOODS which checks that you dont sell cheaper than you bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so you override the constraint for CAMPAIGN_GOODS. What that tells me is that the constraint, valid_prices, shouldn't have been on GOODS in the first place. If it is not a legitimate constraint for the children, then it is not a legitimate constraint for the parent. I don't agree with you on that point. This concept is common to many OO-implementations. Unless you can come up with a powerful argument as to why our to-be picture should never do this, I'm less than convinced. If the plan is for table CAMPAIGN_GOODS to virtually be a view on GOODS, then I'd say it _is_ necessary. In human inheritance, if you marry someone with funny coloured skin, yo= u=20 don't get to choose that your children won't have funny coloured skin.= =20=20 That's a pretty forcible constraint. :-). =20 Is there something broken with your mailer? It's reformatting quotes rather horribly... Fine, but that only works for YOUR specific example. In that example, the color constraint should be non-virtual, meaning, the child should not be able to change it. On the other hand, if I replace human with metal product, hopefully I won't be stuck with gun metal gray for every derived product. Hopefully, somewhere along the lines, I'll be able to override the parent's color constraint. That happens by _adding_ an additional characteristic, presumably that of what kind of paint the metal is covered with. That doesn't override the fundamental constraint that if it's a metal product, there _will_ be metallic properties. If you decide to add in some non-metallic products, then it would be _silly_ to have them inherit all their characteristics from METAL_PRODUCTS; they should head back up the class hierarchy and inherit their basic characteristics from the _appropriate_ parent. Reality, with the GOODS/CAMPAIGN_GOODS example, is that GOODS isn't the appropriate parent class for CAMPAIGN_GOODS. Both should be inheriting the common characteristics from some common ancestor. If that is done, then there's nothing to override. Or maybe it is better to just make the check function should be dynamically dispatched, so the constraint will always hold, it just can mean different things for different types. =20 Or maybe if someone is doing an Object Oriented design, and making extens= ive=20 use of inheritance, they'll need to apply constraints in a manner that al= low=20 them to be properly inherited. The problem with that assumption is that there is normally nothing wrong with having seemingly mutually exclusive sets of *business rules* for a parent and child. If the rules are totally different, it begs the question of why they _should_ be considered to be related in a parent/child relationship. It may well be that they _aren't_ related as parent/child. They may merely be cousins, sharing some common ancestors. -- (concatenate 'string chris @cbbrowne.com) http://cbbrowne.com/info/spreadsheets.html Note that if I can get you to `su and say' something just by asking, you have a very serious security problem on your system and you should look into it. -- Paul Vixie, vixie-cron 3.0.1 installation notes ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0
Jason wrote: If you can support xmlrpc instead, you'll save yourself a lot of headaches. XML-RPC has three merits over SOAP: 1. It's a simple specification, and thus readily implemented. 2. Microsoft and IBM aren't fighting over control over it, so it's not suffering from the we keep adding pseudo-standards to it problem. (Which further complicates the specifications.) You can have a /complete/ implementation of XML-RPC, whereas, for SOAP, you can hold ghastly long arguments as to what SOAP means, anyways. 3. There's a (perhaps not standard, but definitely widely implemented) scheme for bundling multiple XML-RPC requests into one message, which improves latency a LOT for small messages. Of course, CORBA has actually been quite formally standardized, suffers from many fairly interoperable implementations, and is rather a lot less bloated than any of the XML-based schemes. It might be worth trying, too... -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://cbbrowne.com/info/soap.html I just got skylights put in my place. The people who live above me are furious. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Newbie: problem Connecting to Server
Ferindo Middleton Jr [EMAIL PROTECTED] wrote: I'm running Redhat Linux 8. I have registration to the Redhat Network so I'm probably running the latest version of postgresql available. I also have Redhat Databse v2.1 installed, but whenever I try to start a session, I get the following error message: psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? Please help me configure my system so that I can connect and begin to use postgresql. Have you checked to see if it is actually running? I rather expect that it isn't. I think RHAT distributes GUIfied tools to manage services started via init.d, so that even if you are afraid of Unix, you should be able to see what it's doing. And it's quite unlikely that RHAT has packaged the very latest version; the fact that they are numbering things independently is quite irritating as it makes it more difficult to ascertain what version it actually is. -- output = (cbbrowne @acm.org) http://www3.sympatico.ca/cbbrowne/rdbms.html ...while I know many people who emphatically believe in reincarnation, I have never met or read one who could satisfactorily explain population growth. -- Spider Robinson ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
mlw wrote: I think you are interpreting the spec a bit too restrictively. The syntax is fairly rigid, but the spec has a great degree of flexibility. I agree that, syntactically, it must work through a parser, but there is lots of room to be flexible. This is /exactly/ the standard problem with SOAP. There is enough flexibility that there are differing approaches associated, generally speaking, with IBM versus Microsoft whereby it's easy to generate SOAP requests that work fine with one that break with the other. For a pretty simple example of a longstanding bug that has never been fixed, see: http://sourceforge.net/tracker/index.php?func=detailaid=559324group_id=26590atid=387667 The precis: The SOAP implementation used by the XMethods folks to publish stock prices is buggy, rejecting perfectly legitimate messages submitted using ZSI (a Python SOAP implementation). The bug isn't with ZSI; it is quite clearly with the server, apparently implemented in Java using one of the EJB frameworks. In practice, what happens is that since that service is fairly popular, particularly for sample applications, the implementors of SOAP libraries wind up coding around the bugs. The problem is that it gets difficult to tell the difference between bugs and variations in interpretations of the standards. If the specs were more strictly defined, it would be a lot easier to use SOAP, because you wouldn't be left puzzling over whether the interoperability problems you're having are: a) Problems with the client; b) Problems with the server; c) Problems with interpretation of specs; d) ... The vast degree to which messages can get rewritten behind your back adds to the fun. Of course, it's only fun if you *enjoy* having interoperability problems... -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www.ntlug.org/~cbbrowne/soap.html He who laughs last thinks slowest. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
[EMAIL PROTECTED] kirjutas N, 03.04.2003 kell 02:01: mlw wrote: I think you are interpreting the spec a bit too restrictively. The syntax is fairly rigid, but the spec has a great degree of flexibility. I agree that, syntactically, it must work through a parser, but there is lots of room to be flexible. This is /exactly/ the standard problem with SOAP. There is enough flexibility that there are differing approaches associated, generally speaking, with IBM versus Microsoft whereby it's easy to generate SOAP requests that work fine with one that break with the other. Do you know of some: a) standard conformance tests b) recommended best practices for being compatible with all mainstream implementations (I'd guess a good approach would be to generate very strictly conformant code but accept all that you can, even if against pedantic reading of the spec) The problem with a) is that SOAP, unlike CORBA, doesn't have the notion of standardized language bindings. That makes it tough to be sure that your implementation is standard in any meaningful way in the first place. The best practices have involved scripting up interoperability tests where they construct sets of functions with varying data types and verify that my client implementation can talk to your server implementation, and vice-versa. And when you run into problems, you chip off bits of code until the block of stone starts looking like an elephant. In order to have confidence of interoperability, you have to test your client library against all the servers you care about, or vice-versa. That's definitely not the same thing as being a conformance test. Trying to be really strict doesn't seem to be a viable strategy, as far as I can see... -- (concatenate 'string cbbrowne @ntlug.org) http://www3.sympatico.ca/cbbrowne/wp.html The cost of living has just gone up another dollar a quart. -- W.C. Fields ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
I have been planning to test the whole thing with a few .NET applications. I am currently using expat to parse the output to ensure that it all works correcty. That, unfortunately, probably implies that your implementation is almost totally non-interoperable. You should put out of your mind the notion of being correct. Being correct is pretty irrelevant if 80% of the requests that come from a VB.NET client fail because Microsoft implemented part of their request differently than what you interpreted as correct. The point is that correctness isn't the thing you need to aim for; what you should aim for is interoperability with the important client implementations. SOAP::Lite, .NET, probably some Java ones, C++ ones, and such. Nobody does correctness testing; they do interoperability tests where they try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other important implementations. If you're testing a server (as is the case here), then the point is to run tests with a bunch of clients. Head to the SOAP::Lite and Axis projects; you'll see matrices describing this sort of thing... -- (reverse (concatenate 'string ac.notelrac.teneerf@ 454aa)) http://www.ntlug.org/~cbbrowne/advocacy.html Fear leads to anger. Anger leads to hate. Hate leads to using Windows NT for mission-critical applications. --- What Yoda *meant* to say ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
