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] Support (was: Democracy and organisation)
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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Support (was: Democracy and organisation)
-Original Message- From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]] Sent: 27 June 2002 08:08 To: [EMAIL PROTECTED]; Tim Hart Cc: Andrew Sullivan; [EMAIL PROTECTED] Subject: Re: [HACKERS] Support (was: Democracy and organisation) 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. I'm inclined to agree, though if it were the case, just buy Red Hat Database. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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
Re: [HACKERS] Object Oriented Features
On Thu, Jun 27, 2002 at 10:13:26AM +0530, Nishkala wrote: I am a student doing my graduation in India. I want to know what are the other OODBMS features ( other than inheritance ) available in PostGreSQL. It would be great if you can help me out with some information regarding this. The PostgreSQL is Object-Relational DBMS and not clean Object Oriented. The good and short description about DBs types you can read at http://wwwinfo.cern.ch/db/aboutdbs/classification/ I think most of the current used SQL DBs are Object-Relational. OO in PostgreSQL means that you can create own operators, datetypes, functions... Something about really Object Oriented you can found at: http://www.odbmsfacts.com/ Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] BETWEEN SYMMETRIC
Hi, Based on recent discussion, I went thru and got together the work I'd done on the BETWEEN node. It's not as far along as I thought. I ran into a few hurdles: * ExecEvalBetweenExpr is probably beyond my powers - I've done my best and marked my hopelessness with '@@' symbols. I don't know how to actually evaluate the node properly, I don't know how to check that all the 3 types are coercible to the same type and I don't know how to make it take rowvars (sic?)instead of scalars, as per spec. Copy and Equal are done, I think. Out I've guessed at how to do it based on other examples, but I need feedback. Read I haven't done at all cos I don't quite understand when/why it's used or how to do it. The grammar has been updated to use the new BetweenExpr node, with new syntax options. The new keywords have been added in the relevant places, and they are reserved. nodes.h and parsenodes.h are aware of the new node. I have added a full regression test that I used in my old gram.y only implementation, that didn't use a new node - it will be helpful! Where do we go from here? Chris ? GNUmakefile ? between.diff.txt ? config.log ? config.status ? contrib/spi/.deps ? src/Makefile.global ? src/backend/postgres ? src/backend/access/common/.deps ? src/backend/access/gist/.deps ? src/backend/access/hash/.deps ? src/backend/access/heap/.deps ? src/backend/access/index/.deps ? src/backend/access/nbtree/.deps ? src/backend/access/rtree/.deps ? src/backend/access/transam/.deps ? src/backend/bootstrap/.deps ? src/backend/catalog/.deps ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/commands/.deps ? src/backend/commands/tablecmds.c.mystuff ? src/backend/executor/.deps ? src/backend/lib/.deps ? src/backend/libpq/.deps ? src/backend/main/.deps ? src/backend/nodes/.deps ? src/backend/optimizer/geqo/.deps ? src/backend/optimizer/path/.deps ? src/backend/optimizer/plan/.deps ? src/backend/optimizer/prep/.deps ? src/backend/optimizer/util/.deps ? src/backend/parser/.deps ? src/backend/port/.deps ? src/backend/postmaster/.deps ? src/backend/regex/.deps ? src/backend/rewrite/.deps ? src/backend/storage/buffer/.deps ? src/backend/storage/file/.deps ? src/backend/storage/freespace/.deps ? src/backend/storage/ipc/.deps ? src/backend/storage/large_object/.deps ? src/backend/storage/lmgr/.deps ? src/backend/storage/page/.deps ? src/backend/storage/smgr/.deps ? src/backend/tcop/.deps ? src/backend/utils/.deps ? src/backend/utils/adt/.deps ? src/backend/utils/cache/.deps ? src/backend/utils/error/.deps ? src/backend/utils/fmgr/.deps ? src/backend/utils/hash/.deps ? src/backend/utils/init/.deps ? src/backend/utils/mb/.deps ? src/backend/utils/misc/.deps ? src/backend/utils/mmgr/.deps ? src/backend/utils/sort/.deps ? src/backend/utils/time/.deps ? src/bin/initdb/initdb ? src/bin/initlocation/initlocation ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/.deps ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_dump/pg_restore ? src/bin/pg_encoding/.deps ? src/bin/pg_encoding/pg_encoding ? src/bin/pg_id/.deps ? src/bin/pg_id/pg_id ? src/bin/psql/.deps ? src/bin/psql/psql ? src/bin/scripts/createlang ? src/include/pg_config.h ? src/include/stamp-h ? src/interfaces/ecpg/lib/.deps ? src/interfaces/ecpg/lib/libecpg.so.3 ? src/interfaces/ecpg/preproc/.deps ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpgeasy/.deps ? src/interfaces/libpgeasy/libpgeasy.so.2 ? src/interfaces/libpq/.deps ? src/interfaces/libpq/libpq.so.2 ? src/interfaces/libpq++/.deps ? src/interfaces/libpq++/libpq++.so.4 ? src/pl/plpgsql/src/.deps ? src/pl/plpgsql/src/libplpgsql.so.1 ? src/test/regress/.deps ? src/test/regress/log ? src/test/regress/pg_regress ? src/test/regress/regression.diffs ? src/test/regress/regression.out ? src/test/regress/results ? src/test/regress/tmp_check ? src/test/regress/expected/constraints.out ? src/test/regress/expected/copy.out ? src/test/regress/expected/create_function_1.out ? src/test/regress/expected/create_function_2.out ? src/test/regress/expected/misc.out ? src/test/regress/sql/constraints.sql ? src/test/regress/sql/copy.sql ? src/test/regress/sql/create_function_1.sql ? src/test/regress/sql/create_function_2.sql ? src/test/regress/sql/misc.sql Index: src/backend/executor/execQual.c === RCS file: /projects/cvsroot/pgsql/src/backend/executor/execQual.c,v retrieving revision 1.94 diff -c -r1.94 execQual.c *** src/backend/executor/execQual.c 2002/06/20 20:29:27 1.94 --- src/backend/executor/execQual.c 2002/06/27 10:27:30 *** *** 60,65 --- 60,67 static Datum ExecEvalOr(Expr *orExpr, ExprContext *econtext, bool *isNull); static Datum ExecEvalCase(CaseExpr *caseExpr, ExprContext *econtext, bool *isNull, ExprDoneCond *isDone); + static Datum ExecEvalBetweenExpr(BetweenExpr *btest, ExprContext
Re: [HACKERS] Why I like partial solutions
On Wed, 26 Jun 2002, Tom Lane wrote: 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. If the backwards compatability problem is just related to stuff from the users (i.e., this keyword works in this release, but will not work in future releases), I don't see the problem. Just document it and move on. The user can either use it and deal with the compatbility pain later, or not use it and be just where he would be if the hack were never implmemented in the first place. Otherwise you only have to leave the feature in until the next major release, anyway, right? Because for major releases it's expected that you will have to dump and restore you database anyway, hmm? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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
[HACKERS] Case sensitive searches
I've just come across a case in Oracle 8.0.6 where important queries
could have been several orders of magnitude faster if only the optimizer
had realized that it was doing case-insensitive comparisons against a
constant that wasn't affected by case (a string of all digits).
The query was of the general form
SELECT * FROM table
WHERE upper(id) = '001234'
...causing a full index scan (there was a non-unique index on id). What
the optimizer could perhaps have done was something like
if (upper('001234') == lower('001234'))
SELECT * FROM table
WHERE id = '001234';
else
SELECT * FROM table
WHERE upper(id) = '001234';
Even without the index I guess that would have saved it a lot of work.
In this case, of course, the user wasn't doing the smartest thing by
giving millions of records a numerical id but storing it as varchar.
OTOH there may also be a lot of cases like
SELECT * FROM table
WHERE upper(name) LIKE '%'
being generated by not-too-bright applications out there.
Does PostgreSQL do this kind of optimization? If not, how easy and how
useful would it be to build it? I suppose this sort of thing ought to
be in src/backend/optimizer/prep/ somewhere, but I couldn't find
anything like it.
Jeroen
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Case sensitive searches
...
if (upper('001234') == lower('001234'))
SELECT * FROM table
WHERE id = '001234';
else
SELECT * FROM table
WHERE upper(id) = '001234';
Even without the index I guess that would have saved it a lot of work.
I'm no expert, but I can't image this will be easy, because the optimizer
does not know any relation between lower() and upper().
I think an index on upper(id) (create index idxname on table(upper(id)))
should work well.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SQL99, CREATE CAST, and initdb
On Thu, 2002-06-27 at 02:10, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it wouldn't be such a terrible idea after all to store the casting paths separately, such as in a system table pg_cast (from, to, func, implicit). This would implement the SQL99 spec fairly exactly. Well, maybe. One question is how that would fit in with schemas. Thomas appears to want your schema search path to have some effect on which casts you can see --- which I'm not at all sure I agree with, I hope that schema search path has some effect on other user-defined stuff like simple functions and operators. but if that's the requirement then the above doesn't do it either. What is and what is not affected by schemas ? Are the docs on our schema usage already available someplace ? - Hannu ---(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] Postgres idea list
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. Dave On Wed, 2002-06-26 at 14:35, Josh Berkus wrote: Dave, 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. 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. 3. There are compatiblity issues between the various JVMs. We'd have to pick a particular JVM and stick with it, and get a lot of complaints from users on other JVMs. I don't know how serious the issues are. -- -Josh Berkus __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology[EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgres idea list
Dave, Would you consider java as a platform independant language? I have started a project on sf.net called jpgadmin, but I see the duplication of effort as a waste of time. Dave On Wed, 2002-06-26 at 09:45, Dave Page wrote: -Original Message- From: Josh Berkus [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 01:51 To: [EMAIL PROTECTED] Cc: Rod Taylor Subject: Re: [HACKERS] Postgres idea list Folks, What would be a win is an SQL like interface to editing pg_hba.conf and postgresql.conf. Once that was done PG_Admin could write a lovely interface to manage them without requiring direct access to the files. I am going to keep arguing against PG_Admin as the primary solution to any of our administration UI challenges. It's WINDOWS ONLY, darn it! Just for info, *absolute* number 1 priority for the next major release of pgAdmin is to take the 5+ years of experience and rewrite the code in a more platform independent language. Regards, Dave. ---(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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgres idea list
On Wed, 2002-06-26 at 14:50, Josh Berkus wrote: Dave, 1) There is an open source implementation of java Really? I thought Sun had a patent. www.blackdown.org 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. That's great news, especially as we are planning to write a small business accounting package using Postgres, OpenOffice.org, and Java. That's awesome, have you looked at compiere? www.sf.net/projects/compiere 3) Don't see this as a big issue we aren't writing something esoteric here. Cool. As I said, I don't think that any of the issues are prohibitive. BTW, does anyone on this list know about Command Prompt, Inc.'s tools? There seems to be a lot of duplicte development going on in the commercial space. Ya, they're on the list -Josh Berkus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[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
[HACKERS] encoding problem
Hi i just upgrading postgres from 7.0 to 7.2 and i have the folowing error in configuration process what happen ? how to fix this problem ? Enter default encoding (SQL_ASCII): Now installing the PostgreSQL database files in /var/lib/postgres/data su - postgres -c cd /var/lib/postgres; . ./.profile; LANG= initdb --encoding SQL_ASCII --pgdata /var/lib/postgres/data /usr/lib/postgresql/bin/pg_encoding: relocation error: /usr/lib/postgresql/bin/pg_encoding: undefined symbol: pg_char_to_encoding initdb: pg_encoding failed -- ___ Fouad Fezzi Ingenieur Réseau IUP Institut Universitaire Professionnalisé Universite d'Avignon et des Pays de Vaucluse 339 ch. des Meinajaries tel : (+33/0) 4 90 84 35 50 BP 1228 - 84911 AVIGNON CEDEX 9 fax : (+33/0) 4 90 84 35 01 http://www.iup.univ-avignon.fr _ ---(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] Postgres idea list
Josh, What do you see as the drawbacks with java, and how can they be circumvented? Dave On Wed, 2002-06-26 at 14:08, Josh Berkus wrote: Daves, Would you consider java as a platform independant language? I have started a project on sf.net called jpgadmin, but I see the duplication of effort as a waste of time. Java has its drawbacks, but a JPgAdmin tool would significantly encourage Postgres-OpenOffice.org integration. -- -Josh Berkus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Democracy and organisation : let's make a revolution
Marc, I tried to create it on gborg originally, but could not complete the form ?? But to answer your question I would prefer to have it at gborg, so I will try again and let you know the results. Dave On Wed, 2002-06-26 at 10:21, Marc G. Fournier wrote: could we get this added to gborg and a link created to it? we're working on marketing Gborg, and the software that is listed there, and Chris added (at my request) in code to the 'news' section so that whenever there are changes, it automatically gets sent to the -announce list so that ppl are aware of changes/enhancements/news ... On 26 Jun 2002, Dave Cramer wrote: I have started a java admin tool on sourceforge just 2 weeks ago actually, www.sf.net/jpgadmin Dave On Wed, 2002-06-26 at 02:51, Christopher Kings-Lynne wrote: What other development options do we have for soemthing that is GUI and portable to all platforms that postgresql runs on? Java? wxWindows? Qt? Gtk? I would think that Gtk is probably the most portable, and it has bindings to many languages, but we would probalby want to use C. TOra uses QT and is cool. Unfortunately Windows version costs money. It is utterly, totally awesome though. Don't know how good its Postgres support is working at the moment, tho. http://www.globecom.se/tora/ Chris ---(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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgres idea list
On Thu, 27 Jun 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: http://archives.postgresql.org/ ... better? Yup, although I'd suggest making the classification line up with the one on the main website --- docs and cygwin are listed as developer lists there. Also, someone suggested listing the by-month indexes back-to-front (most recent month first), which seems like a great idea if not difficult. Better? http://archives.postgresql.org/pgsql-jdbc The rest will 'fall in line' once there is something for mhonarc to work on again ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgres idea list
Also, someone suggested listing the by-month indexes back-to-front (most recent month first), which seems like a great idea if not difficult. Better? http://archives.postgresql.org/pgsql-jdbc The rest will 'fall in line' once there is something for mhonarc to work on again ... I don't think I've been so happy to see a webpage. Much better. Curious how there is a 'search the archives' link going to FTS when there is a form at the top of the page using another mechanism. ---(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] Fwd: Support (was: Democracy and organisation)
On Thu, 2002-06-27 at 02:52, Tim Hart wrote: 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. Perhaps, but in this case who protects Oracle from the insurance company when the insurance agency Oracle based database corrupts and loses the Oracle policy? This is why I think Oracle should promote PostgreSQL for instances where a database issue could be conflicting ;) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Postgres idea list
On 27 Jun 2002, Rod Taylor wrote: Also, someone suggested listing the by-month indexes back-to-front (most recent month first), which seems like a great idea if not difficult. Better? http://archives.postgresql.org/pgsql-jdbc The rest will 'fall in line' once there is something for mhonarc to work on again ... I don't think I've been so happy to see a webpage. Much better. Curious how there is a 'search the archives' link going to FTS when there is a form at the top of the page using another mechanism. two different methods of searching ... those pages still need one helluva lot of cleanups though, as I shoudl re-word that 'Search the archives' as something more like 'Alternative methods of searching' or something like that, and point to FTS and Google ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] encoding problem
Fouad Fezzi [EMAIL PROTECTED] writes: i just upgrading postgres from 7.0 to 7.2 and i have the folowing error in configuration process what happen ? how to fix this problem ? Enter default encoding (SQL_ASCII): Now installing the PostgreSQL database files in /var/lib/postgres/data su - postgres -c cd /var/lib/postgres; . ./.profile; LANG= initdb --encoding SQL_ASCII --pgdata /var/lib/postgres/data /usr/lib/postgresql/bin/pg_encoding: relocation error: /usr/lib/postgresql/bin/pg_encoding: undefined symbol: pg_char_to_encoding initdb: pg_encoding failed I think that you configured 7.2 with multibyte support but that the old 7.0 installation didn't have it, and for some reason the dynamic linker is trying to bind the old libpq.so instead of the new one. Check where you've installed the library, check ldconfig path, etc. regards, tom lane ---(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] Postgres idea list
-Original Message- From: Dave Cramer [mailto:[EMAIL PROTECTED]] Sent: 27 June 2002 12:12 To: Dave Page Subject: RE: [HACKERS] Postgres idea list Dave, Thanks for the response. On Wed, 2002-06-26 at 15:21, Dave Page wrote: I do, but I've had nothing but bad experiences with Java though I'm open to new evidence/persuasion. I do agree that duplication of effort is not a good idea and I'm certainly not against collaborating on a new version though I must point out that having written pgAdmin from scratch twice now (three times if you cound my original proof of concept) over the last 5-6 years, I have *very* specific ideas on how pgAdmin should work. I've heard this bad experience thing a few times and I would like to understand this better. I have been developing in java for quite some time now, and have no worse, or better time with it. Most recently, the Cisco Visual Switch manager app that's in the firmware of my 2950-24 switches which won't run on any Linux or Win32 system I've got within 6 feet of me. You'd think they'd get it right. I have often found that applets from various places give exception errors and refuse to run. Others are extremely slow. On the plus side, there is a Java Telnet app that I used to use that was *very* good. Let me say now though, even if I do stay with my own version, if you ever need help don't hesitate to ask. Thanks very much for the offer, actually your code is quite helpful. :-) Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Can't read archives anymore :-(
Marc, did you do anything to the format of the individual archive message pages? The top index pages look great, but when I go to, say, http://archives.postgresql.org/pgsql-hackers/2002-05/index.php I see only a blank page. View Source shows there is stuff there, but my browser ain't coping. Maybe a missing end-tag or something? regards, tom lane ---(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 I like partial solutions
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. I absolutely agree on that. If we at some point want to have a given feature, we need to avoid backward compatibility problems. As for features that are independent, don't break anything, just add-on's that can happily swim around in contrib (but stay out of the deep water), we might want to become a bit more relaxed again. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can't read archives anymore :-(
shows up fine for me ... browser issue? :( is there a tag missing that you can pick out in view source? *raised eyebrow* On Thu, 27 Jun 2002, Tom Lane wrote: Marc, did you do anything to the format of the individual archive message pages? The top index pages look great, but when I go to, say, http://archives.postgresql.org/pgsql-hackers/2002-05/index.php I see only a blank page. View Source shows there is stuff there, but my browser ain't coping. Maybe a missing end-tag or something? regards, tom lane ---(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] Can't read archives anymore :-(
Marc G. Fournier [EMAIL PROTECTED] writes: shows up fine for me ... browser issue? :( is there a tag missing that you can pick out in view source? *raised eyebrow* Looks like table problems. I tried W3C's validator on it, and it had a ton of minor gripes, but the missing table end-tag is probably the killer: http://validator.w3.org/check?uri=http%3A%2F%2Farchives.postgresql.org%2Fpgsql-hackers%2F2002-05%2Findex.phpcharset=iso-8859-1+%28Western+Europe%29doctype=HTML+4.01+Strict regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SQL99, CREATE CAST, and initdb
Hannu Krosing [EMAIL PROTECTED] writes: Are the docs on our schema usage already available someplace ? Yes, although there's not a pulled-together introduction (someone needs to write a section for the tutorial, I think). Try http://developer.postgresql.org/docs/postgres/sql-naming.html and see the SEARCH_PATH variable at http://developer.postgresql.org/docs/postgres/runtime-config.html#RUNTIME-CONFIG-GENERAL as well as the schema-aware rules for resolution of overloaded functions and operators: http://developer.postgresql.org/docs/postgres/typeconv-func.html http://developer.postgresql.org/docs/postgres/typeconv-oper.html also various new functions at http://developer.postgresql.org/docs/postgres/functions-misc.html http://developer.postgresql.org/docs/postgres/datatype-oid.html regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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] Non-standard feature request
On Fri, 14 Jun 2002, Gavin Sherry wrote:
On Thu, 13 Jun 2002, Mike Mascari wrote:
CREATE TEMPORARY TABLE
...
ON COMMIT DROP;
pseudo-compatible with the SQL-standard of:
ON COMMIT { DELETE | PRESERVE } ROWS;
so one day PostgreSQL's grammar would look like:
...
ON COMMIT { DROP | { DELETE | PRESERVE } ROWS };
I think this is a pretty useful feature. Shouldn't require too much
work. A new relkind or a bool in TempTable and a little code in
AtEOXact_temp_relations() to heap_drop_with_catalog() the registered temp
table.
Anyone else keen for this feature?
Attached is a patch implementing this. The patch is against 7.2.1
source. The grammar introduced is of the form:
CREATE TEMP TABLE ... ON COMMIT DROP;
Is this a desirable feature? Seems pretty useful to me.
Gavin
temprel.diff.gz
Description: GNU Zip compressed data
---(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)
Tim, 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. Well, there's the perception and the reality. I can't argue that company lawyers and auditors will *not* make the above argument; they very well may, especially if they are personally pro-MS or pro-Oracle. You may be on to something there. However, the argument is hogwash from a practical perspective. In pratice, it is nearly impossible to sue a company for bad software (witness various class actions against Microsoft). SO much so that one of the hottest-debated portions of the vastly flawed UCITA is software liability and lemon laws. Plus in some states, the vendor's EULA (which always disclaims secondary liability) is more powerful than local consumer law. 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. As I said, I don't disreagard your argument. Just because it's hogwash doesn't mean that people don't believe it. -Josh Berkus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Non-standard feature request
Slight bug in the previous patch. Logically (and according to SQL99's
treatment of ON COMMIT), it can be specified only for CREATE TEMP
TABLE. The patch throws an error if only CREATE TABLE has been specified.
Gavin
On Fri, 28 Jun 2002, Gavin Sherry wrote:
On Fri, 14 Jun 2002, Gavin Sherry wrote:
On Thu, 13 Jun 2002, Mike Mascari wrote:
CREATE TEMPORARY TABLE
...
ON COMMIT DROP;
pseudo-compatible with the SQL-standard of:
ON COMMIT { DELETE | PRESERVE } ROWS;
so one day PostgreSQL's grammar would look like:
...
ON COMMIT { DROP | { DELETE | PRESERVE } ROWS };
I think this is a pretty useful feature. Shouldn't require too much
work. A new relkind or a bool in TempTable and a little code in
AtEOXact_temp_relations() to heap_drop_with_catalog() the registered temp
table.
Anyone else keen for this feature?
Attached is a patch implementing this. The patch is against 7.2.1
source. The grammar introduced is of the form:
CREATE TEMP TABLE ... ON COMMIT DROP;
Is this a desirable feature? Seems pretty useful to me.
Gavin
temprel2.diff.gz
Description: GNU Zip compressed data
---(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] Non-standard feature request
Gavin Sherry wrote: Slight bug in the previous patch. Logically (and according to SQL99's treatment of ON COMMIT), it can be specified only for CREATE TEMP TABLE. The patch throws an error if only CREATE TABLE has been specified. ... Attached is a patch implementing this. The patch is against 7.2.1 source. The grammar introduced is of the form: CREATE TEMP TABLE ... ON COMMIT DROP; Is this a desirable feature? Seems pretty useful to me. Great! I'm give this a try. Mike Mascari [EMAIL PROTECTED] ---(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
Re: [HACKERS] Support (was: Democracy and organisation)
Is this sort of like Oracle guaranteeing its uncrackable, but as soon as someone comes to them to prove it is, Oracle's response is but DBA didn't enable the obscure security feature that can be found here, that is disabled by default? On Thu, 27 Jun 2002, Tim Hart wrote: 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 ---(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] Object Oriented Features
Karel, OO in PostgreSQL means that you can create own operators, datetypes, functions... Last I checked, all of these things were part of the SQL spec. I believe our only OO functionality is inheritance ... which I have yet to find a use for. Of course, I agree with Fabian Pascal, who claims that every OODBMS feature has an answer in the SQL spec that is more consistent and better thought out. -- -Josh Berkus ---(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] Object Oriented Features
Last I checked, all of these things were part of the SQL spec. I believe our only OO functionality is inheritance ... which I have yet to find a use for. Well, it's lower maintenance than the 14-clause SELECT...UNION...UNION... I'd have to write for ``correct'' code, in my current project. :-) -- Christopher Clark [EMAIL PROTECTED] Pongidae, and proud of it. Darn it, who spiked my coffee with water? -- Larry Wall ---(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] Object Oriented Features
On Fri, 2002-06-28 at 03:21, Josh Berkus wrote: Karel, OO in PostgreSQL means that you can create own operators, datetypes, functions... Last I checked, all of these things were part of the SQL spec. I believe our only OO functionality is inheritance ... Actually _single_ inheritance is also part of SQL99 create table ... under ... which I have yet to find a use for. It will become much more useful once implemented more thoroughly ;) --- Hannu ---(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] SQL99, CREATE CAST, and initdb
Tom Lane writes: Thomas appears to want your schema search path to have some effect on which casts you can see --- which I'm not at all sure I agree with, but if that's the requirement then the above doesn't do it either. If I understand this right, this would be nearly analogous to determining an operator's underlying function by schema path. That smells an awful lot like dynamic scoping, a.k.a. a bad idea, and completely inconsistent with the rest of the system. If we just want to get out from under the coupling of function name to cast status, the above would do it ... and also break existing applications that aren't expecting to have to do something special to make a function of the right name become a cast function. Perhaps there could be a GUC variable to allow created functions matching the old naming convention to be automatically made into casts? We could default it to 'true' for a release or two and then default to 'false'. Sure. However, AFAIK, the current development progress has already broken the previous expectations slightly by requiring that implicit casting paths be explicitly declared. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Object Oriented Features
OO in PostgreSQL means that you can create own operators, datetypes, functions... Last I checked, all of these things were part of the SQL spec. I believe our only OO functionality is inheritance ... which I have yet to find a use for. Can you tell me what the SQL99 spec says regarding creation of operators? I couldn't find them. -- Tatsuo Ishii ---(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] Can't read archives anymore :-(
On Thu, 27 Jun 2002, Tom Lane wrote: ...but the missing table end-tag is probably the killer: That kills me in Netscape 4.78 all the time. It's a well known problem. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Non-standard feature request
Anyone else keen for this feature? Attached is a patch implementing this. The patch is against 7.2.1 source. The grammar introduced is of the form: CREATE TEMP TABLE ... ON COMMIT DROP; Is this a desirable feature? Seems pretty useful to me. It's useful, there's a patch - what more do we want!!! Chris ---(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] SQL99, CREATE CAST, and initdb
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Thomas appears to want your schema search path to have some effect on which casts you can see --- which I'm not at all sure I agree with, but if that's the requirement then the above doesn't do it either. If I understand this right, this would be nearly analogous to determining an operator's underlying function by schema path. That smells an awful lot like dynamic scoping, a.k.a. a bad idea, and completely inconsistent with the rest of the system. I don't like it either. ISTM that the casting relationship between two types is a property of those types and should *not* be affected by your search path. Maybe you referenced one or both types by qualified schema names, rather than by finding them in your path, but should that keep you from seeing the cast? Especially since there's no obvious place in the CAST syntax to attach a schema qualification, if we try to insist that one might be needed to get at the desired cast function. An extreme case is binary-equivalence, which as I mentioned maps nicely into the sort of pg_cast table you suggested. It doesn't map nicely into anything that involves schema visibility --- there is no cast function to hide or make visible. Even more to the point, if types A and B are binary-equivalent, should changing my search path make them stop being so? Doesn't make sense to me. Sure. However, AFAIK, the current development progress has already broken the previous expectations slightly by requiring that implicit casting paths be explicitly declared. True. If we wanted to maintain the old behavior exactly then we could allow this hypothetical GUC variable to also cause old-convention cast functions to be automatically marked IMPLICIT CAST. (I suppose the IMPLICIT CAST bit would actually stop being a property of functions at all, and would become a column of pg_cast.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
