Re: [HACKERS] [SQL] line datatype
Actually... as one with the vested interest... I'm not opposed to entering an equation in one of the basic algebraic forms. Given that line types and line segment types both exist, I'm happy to weigh the cost/benefit between choosing an lseg and entering 2 points, or choosing a line and entering the equation. Are there database functions to translate between a line and a line seg? If so, that would address my only reservation for restricting the line type to an equation. And - to address Tom's continuing concern over casting ;), I have no need for implicit casts in this case. If there are concerns about precision being lost in the translation - As long as what precision can be guaranteed is documented, I have no qualms. If I needed absolute precision I'd create my own line table with numerics, and write my own functions as necessary. The line type to me is there for speed and ease of use, not unlimited precision. On Tuesday, 16, 2002, at 09:38AM, Bruce Momjian [EMAIL PROTECTED] wrote: No one likes entering an equation. Two points seems the simplest. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Support (was: Democracy and organisation)
I have an slightly different perspective on this. I hope it will be a bit useful Background: I'm a senior developer for a consulting firm. I too have experience with DB/2, Oracle, Sybase, Adabase, and M$ SQL. In the last few years of work I've been moving from the technical side of things to be business side ( all together now: eew> ). I've been following PostgreSQL for a couple of years now. Absolutely love it. I have never implemented it on a business project, though. Not by any personal desire to use or not to use it. Usually the db choice is out of my hands. I cannot say personally that PostgreSQL support is amazing - ( once again, no experience at all to draw on ), however, I've been following the lists closely enough over the last few years that I believe the statement to be accurate. I can say that support services from the other vendors really aren't all that spectacular. Perspective: There is one factor to database choice that I haven't seen listed here. Culpability legal retribution. I'm not a lawyer, and don't claim to be - so I welcome any corrections to the accuracy of the following. Regardless of its' legal accuracy, I can vouch for the common belief in the following thought by corporate I.T. management. Any corporation, whether privately or publicly held, has various legal obligations to it's shareholders. Executive officers share in both the financial rewards of a successful company and in the legal responsibility that the corporation has to it's shareholders. If a catastrophic software failure results in a high percentage of lost revenue, a corporation might be able to seek monetary compensation from a commercial vendor. They could even be taken to court - depending upon licensing, product descriptions, promises made in product literature, etc. For cases like open source projects, like PostgreSQL, there is no legal recourse available. So - in the extreme case, if commercial Vendor V's database blows chunks, and causes company B to loose a lot of money. If Company B can prove that the fault lies squarely on the shoulders of Vendor V, Company C can sue Vendor V's a** off. Executive management isn't at fault - because they have performed due diligence and have forged a partnership with vendor V who has a legal responsibility for the claims of their product. If, however, the database was PostgreSQL, then Company C has no legal recourse. Executive management has personally taken all responsibility for any catastrophic software failures, and therefore have put themselves in quite a precarious situation. No one else to take the blame but them! Now frankly I know that the above scenario is extreme. I was rolling my eyes while *writing* it. But the truth is that these are the kinds of things that technical auditors would report to a Board of Directors. There is nothing wrong with executive management choosing to assume risk (outside of corporate politics, that is ). Many savvy members of management realize that the real risk is quite low. Of course, the comfort level goes way up when the database is supporting a non-vital business process - or a process that is several steps away from the revenue stream. Still - imagine a database system with data and transactional volume the size of Google. In this case the volume of updates inserts is much higher. Now this database is a companies' main source of revenue ( again, extreme, but we're talking examples ). Would you blame a corporate exec if he wasn't willing to place his own personal assets on the line by choosing PostgreSQL over Oracle? BTW - Oracle other commercial vendors handle these contingencies by buying insurance policies. If the above situation had occurred and Oracle was the vendor, then the two companies would most likely settle out of court by dealing with the insurer. I dunno exactly how the claims process works on such a beast, but I know that such policies are purchased ( and you thought the annual support fee was just to cover the support staff's salaries?). Maybe Oracle would file a claim, an adjuster would visit Oracle's customer, etc? Closing: I think PostgreSQL is a great database. I haven't explored it's good and bad points thoroughly enough to know what applications it serves best, and where it's weakest. I do hope to use it in enough scenarios to find out. I hope a lawyer reads this and tells me that regardless of what management thinks is true, the above is hog-wash. Until someone does, I can't ignore the fact that a commercial vendor has a legal responsibility to support the claims of their product, while an open source group does not. I think PostgreSQL specifically keeps all of their claims legitimate and reasonable, but that doesn't change the fact that if someone makes an honest mistake, there is nothing that can be done *legally* to make you correct your mistake or pay for the damage it caused. Andrew Sullivan wrote: Followup set to -advocacy On Wed, Jun 26, 2002 at 12:01:18PM -0700, Dann Corbit
Re: [HACKERS] Stalled post to pgsql-hackers
Begin forwarded message: I said: BTW - Oracle other commercial vendors handle these contingencies by buying insurance policies. I think I should probably correct the above statement. I think Oracle specifically has a large enough revenue stream that they have no need to purchase an insurance policy. It is technically possible for them, or any other vendor, to do so if they chose to. Many insurance companies offer insurance products to offset the legal responsibility for the performance of a software package. Many such policies are sold each year. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why I like partial solutions
I think PostgreSQL's standards are a bit too high. From my point of view, the team as a whole has no desire to build the worlds best open source database from the point of view of functionality. They seem more interested in the writing the open source database with the world's most aesthetically pleasing source code. Now - in all fairness, I do software architecture for a living, and I can't stand hacks. I fight against them *almost* every opportunity that I get, because I'm loathe to produce such slop. I know that the more slop gets in my code, the harder it is to enhance and maintain, and the more likely it is to actually break code slow down the pace of development. I also must admit that aesthetically pleasing source code almost *always* means that the functionality that is there is rock solid. That functionality was also 'purchased' at the highest price possible. But I also know that functionality has value to the customer. Customers have very little concern for the aesthetics of proper design and implementation. The customer I work with right now has a slogan that I think summed it up well for all customers in general: ( I want it all, and I want it now ). All the valid technical arguments I have don't mean a thing. To the customer, functionality A translates to work savings B. The process can be well defined. Implement it. When I tell her that the cost of implementation is some high value 'X' ( cost in terms of time and/or $$ ), she doesn't say 'I'll wait'. She says. "Hmm... what can I get for X/4?" When I tell her, she then says: "Can I get A/4 now, and can you give me most of the rest of A in 4 months? That's more important to me than functionality Y, and I can do without this bit of spit and polish that was part of A." So I deliver A/4 now, and she uses it now. She receives immediate benefit. She uses the product. She's happy. I clean up my hack while I deliver the other portion of A that she wanted. Now I know that business processes are a far cry from database features. They are less complex and adding a new feature doesn't always carry the potential repercussions that a poorly thought out database feature could cause. Nonetheless, you tell me today that I can shrink indexes with tool X, but tool X is a hack and likely to change, and I'll use tool X because the value of shrinking outweighs the cost of changing to the chrome-plated tool Y when it comes out next year. I may choose not to use another tool because it's also a hack and not that important to my implementation. My choice. In fact, I've found it less costly to deal with vendors cleaning up their hacks( i.e., breaking backwards compatibility ) than in trying to implement my own solution for said feature and trying to replace it when the database finally implements the feature. I'm not advocating that you put in every hack. There's always a balance between judging a whim and a genuine need. A good development effort can also tolerate only a limited number of 'unresolved hacks' at a time. Fair enough. But an application developer with a need for a database feature is going to pick the database solution with that feature set implemented *today*. Whether or not it's a hack will not keep them from using it. It will keep a seasoned developer from relying *too heavily* on it. But there's only so much you can do to protect the users from themselves. Warning labels on tools is fair warning. Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED]> writes: So, when we review patches, we shouldn't be turning up our noses at imperfect solutions if the solution meets needs of our users. I think our standards have gone up over the years, and properly so. The fact that we put in hacks some years ago doesn't mean that we still should. I don't really mind hacks^H^H^Hpartial solutions that are clean subsets of the functionality we want to have eventually. I do object to hacks that will create a backwards-compatibility problem when we want to do it right. regards, tom lane
[HACKERS] Fwd: Support (was: Democracy and organisation)
Begin forwarded message: I said: BTW - Oracle other commercial vendors handle these contingencies by buying insurance policies. I think I should probably correct the above statement. I think Oracle specifically has a large enough revenue stream that they have no need to purchase an insurance policy. It is technically possible for them, or any other vendor, to do so if they chose to. Many insurance companies offer insurance products to offset the legal responsibility for the performance of a software package. Many such policies are sold each year. ---(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] Support (was: Democracy and organisation)
Could very well be. As I said, I'm not a lawyer. I do know that depending upon the laws in a region, EULAs can be proven to be legally invalid. I do personally find it hard to believe that Oracle could be legally immune from *all* damages claims. In practice proving fault could be very hard to do ( It was the DBA's fault - incorrect configuration, or The OS has a bug in it), but in general when a fee is paid for a good or service, there is an implied legal contract that at times can supercede any EULA. The good or service provider has some legal responsibility for the accuracy of their claims regarding the service provided, or the functionality of the project delivered. For example, the only clause that Ford Motor company could use in a sales contract that would absolve them from lemon laws is basically The product you are buying is a lemon. Your point is taken, though - I don't think one could succesfully sue Microsoft if Windows crashes from time to time. However, if M$ promises that product X is a complete COTS datacenter, and you buy X and find that X is nowhere near stable as the industry norm, you have a legal case - both for the cost of the product and in the resulting lost revenue. I probably failed to convey in my initial post that I don't think the scenario is likely. Building and maintaining a db app involves technical talent on the part of the client, reliable hardware, networking, appropriate facilities, blah, blah, blah. So it's likely that blame can't be placed on one thing - and no single fault is probably large enough to be outside the industry norms for reliability of the product. I was merely trying to convey managements mindset. I feel the thinking is flawed as well. On Thursday, 27, 2002, at 01:08AM, Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Hmmm... I think this is a common fallacy. It's like arguing that if windoze crashes and you lose important data then you have some sort of legal recourse against Microsoft. Ever read one of their EULAs? $10 says that Oracle's license grants them absolute immunity to any kind of damages claim. Chris --- Tim Hart Wrote: If a catastrophic software failure results in a high percentage of lost revenue, a corporation might be able to seek monetary compensation from a commercial vendor. They could even be taken to court - depending upon licensing, product descriptions, promises made in product literature, etc. For cases like open source projects, like PostgreSQL, there is no legal recourse available. So - in the extreme case, if commercial Vendor V's database blows chunks, and causes company B to loose a lot of money. If Company B can prove that the fault lies squarely on the shoulders of Vendor V, Company C can sue Vendor V's a** off. Executive management isn't at fault - because they have performed due diligence and have forged a partnership with vendor V who has a legal responsibility for the claims of their product. ---(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] Support (was: Democracy and organisation)
On Thursday, 27, 2002, at 10:07AM, Josh Berkus [EMAIL PROTECTED] wrote: Or from a financial perspective: An enterprise MS SQL 2000 user can expect to pay, under Licensing 6.0, about $10,000 - $20,000 a year in licnesing fees -- *not including any support*. Just $2000-$5000 buys you a pretty good $10 million software failure insurance policy. Do the math. -Josh Berkus The statement above has brought something to light that I had never really considered... Will an insurance company issue a software failure policy against PostgreSQL? If so, that may help me in my own struggles to convince managment that they're current approach to mitigating their risk is not only flawed, but *financially impracticle*. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
