Re: [GENERAL] Writing oracle/postgress generic SQL
On Fri, 23 Feb 2007, David Fetter wrote: > On Fri, Feb 23, 2007 at 08:28:06AM -0800, Richard Troy wrote: > > On Fri, 23 Feb 2007, David Fetter wrote: > > > On Fri, Feb 23, 2007 at 10:23:56AM +0100, Ben Edwards wrote: > > > > Anyone know of any guidelines for writing SQL which works under > > > > Oracle witch will also work under postgress. This is to ensure that > > > > SQL written for an Oracle database can be migrated to postgress > > > > later. > > > > > > You've just bumped into the problem that while standard SQL exists, > > > only Mimer and possibly DB2 implement it. The presentation below > > > outlines your main choices for supporting more than one DB back-end, > > > and they're all expensive and troublesome to maintain. > > > > > > http://www.powerpostgresql.com/Downloads/database_depends_public.swf > > > > With all due respect to Josh's presentation, there's a lot more to > > the story than those couple of slides. > > With all due respect, the presentation was if anything an > understatement. Yes; it didn't say very much. I'm sure Josh, as speaker, articulated what wasn't in those slides, but we didn't get the benefit of that on the web. > Unless, as with rare beasties like Science Tools, the > major purpose of the application is to support multiple DBMS > back-ends, it's just too expensive. Even in those rare cases, it's > expensive. I guess anything you have to pay for is too expensive. (Sounds like dogma to me. And you know what dogma makes - just don't step in it.) > > Are there things it misses? Yes, but not much. I'll take the wild > > guess that more than 80% of applications are completely and > > adequately served. > > That says something about the applications you've seen, and not about > the adequacy of such a library. That remark is uninformed and arrogantly presumptuous about both me and the library, and uninsightful regarding the implementation of applications. It's also needlessly offensive, if you'll forgive the pun. > What point is there in using a > powerful tool like an RDBMS and then hobbling yourself by only using > 10% of the available features? It's certainly a bad thing to do by > default. 10%? Whatever. I never said anything of the kind - and I'm reminded that an unsupported argument can be dismissed without support. But there ARE good reasons. We read on this very list about two weeks ago a long treatise on the subject by an obviously long-in-the-tooth DBA type who articulately took at least four pages to tell us why it was his practice and advice to always be able to move to another RDBMS. Perhaps read the archives and become informed... > > It has pass-through capability so you can still get at engine-specific > > features, though it does completely side-step stored procedures > > Oops! There went 60% of the code in some of the databases I've seen > in production. 80% in at least one case I've seen in the past year. Lots of people use stored procedures and some people over-use them while some others under-utilize them in their architectures. It should be no surprise that some people follow dogma while others consider every arrow in their quiver. Yet I detect a certain flippant bigottry in your response - Oops! Perhaps a more considered argument would be effective than just an attack - that is, presuming there's a considered argument to be made. The short of it is that Science Tools is surely not alone in having developed an SQL dialect translator, though we may be the only ones to offer it to customers. Either way, automated dialect translation, whether by us otherwise, is another useful choice whether _you_ like it or not. Ciao, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Writing oracle/postgress generic SQL
On Fri, 23 Feb 2007, David Fetter wrote: > On Fri, Feb 23, 2007 at 10:23:56AM +0100, Ben Edwards wrote: > > Anyone know of any guidelines for writing SQL which works under > > Oracle witch will also work under postgress. This is to ensure that > > SQL written for an Oracle database can be migrated to postgress > > later. > > You've just bumped into the problem that while standard SQL exists, > only Mimer and possibly DB2 implement it. The presentation below > outlines your main choices for supporting more than one DB back-end, > and they're all expensive and troublesome to maintain. > > http://www.powerpostgresql.com/Downloads/database_depends_public.swf With all due respect to Josh's presentation, there's a lot more to the story than those couple of slides. (They were meant to be given, I'm sure, along with a talk in which the speaker provided most of the value.) And I don't think launching an attack on MySql is helpful to this dialogue, though I do understand the point Josh is making... There are other choices. For example, Science Tools, back in 1997, faced with the similar but slightly different problem of being a vendor supporting multiple RDBMSes for client data, could have taken the typical choice of managing different code branches for each of the RDBMSes it supports. Instead, we wrote an SQL dialect translator that presently supports five (and soon six) RDBMS platforms - and could probably support all the rest if only someone cared enough to configure them - and this translator is available to customers, not just embeded for the exclusive use of Science Tools' applications. You link your user-application code to our library and you can send it any version of SQL, either statically or dynamically, and it automatically translates into the correct dialect for the database engine you're connected to. It does both DDL and DML and it has command-line tools available, too, so you don't have to link your apps if you don't want to. Presently supported are: Postgres (of course!), Informix, DB2, Sybase, and also Oracle - yes, of course, them, too. (OpenIngres is undergoing testing right now for certification sometime this spring.) Are there things it misses? Yes, but not much. I'll take the wild guess that more than 80% of applications are completely and adequately served. It has pass-through capability so you can still get at engine-specific features, though it does completely side-step stored procedures as these are vastly harder to automate conversion of - we just do the SQL. When calling a DBMS from our library, we handle error recovery, database reconnection, optional DBMS independent journaling and even important aspects of security. When parsing DDL, it (optionally) throws warnings of incompatability, though, as a practical matter, most engines have now removed most of their older limitations that made this vital in their earlier versions. (We support versions of all five since about 1997 and, as there were so many small changes along the way, we provide a configuration mechanism where you can tell it the limitations of your version such as attribute length, maximum length of varchar, etc.) Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 1: 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: [GENERAL] Problems shutting down Postmaster
On Thu, 8 Feb 2007, Andrew Edson wrote: > Someone else added the IP address for the other system to the > pg_hba.conf file later, but since we had already started postgres by > then, it didn't take. And now, for some reason, postgres doesn't seem > to want to let me shut down. Try telling Postgres about your new pg_hba.cfg file by using pg_ctl reload I'm not aware why you couldn't just stop it with pg_ctl stop even with the wrong pg_hba.conf file. HTH, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] Production systems beware: U.S. Daylight Savings Time comes at a new time this year
Hello All, it was recently brought to my attention that last year the U.S. altered the dates when Daylight Savings Time starts and ends. Many if not most computers presume the old change dates and therefore, if left to change automatically, will change at the wrong times. This will be vital for people in the database community who manage applications that need accurate timestamps. You can read up on this issue here, among other places: http://www.washingtonpost.com/wp-dyn/content/article/2007/01/31/AR2007013102318.html?referrer=emailarticle I've never investigated how NTP servers handle DST changes - that is, whether they switch with the fabrication that we have more daylight hours or leave it to clients. Hmmm... Anybody know? It'd be nice to know that we can trust our NTP servers to tell our systems what time it is and therefore ignore this issue for those systems that are NTP clients. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Any Plans for cross database queries on the same server?
On Wed, 31 Jan 2007, Jeff Davis wrote: > > I know this is off-topic for this list, but is there a place I can get > some details about linux OOM killer, and the conditions that cause this > OS hang when you turn off the OOM killer? I'd like to really know what's > happening, and also know more about the OS hanging condition that you're > talking about. I'd also like to know how safe the "safe" settings really > are ( vm.overcommmit_memory=2 and vm.oom-kill=0? ). > > Right now I'm using FreeBSD (in a large part due to the Linux OOM > killer), but I have a different set of problems on FreeBSD. > > Regards, > Jeff Davis ...Back in, oh, October perhaps it was, I did some research on this subjet and posted my findings on one of the PG lists, so you can look into the PG archives for OOM and my name and likely find a summary and some URLs to more complete information. Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Any Plans for cross database queries on the same server?
On Wed, 31 Jan 2007, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Tue, Jan 30, 2007 at 04:43:14PM -0800, Richard Troy wrote: > >> ... different in my opinion if only Unix didn't have this asenine view > >> that the choice between a memory management strategy that kills > >> random processes and turning that off and accepting that your system > >> hangs is a reasonable choice and that spending a measily % of > >> performance in overhead to eliminate the problem is out of the > >> question. Asenine, I tell you. > > > The OOM killer in Linux is, indeed, asinine. > > Well, it probably has some use for desktop systems, or would if it could > distinguish essential from inessential processes. But please Richard: > Linux is not Unix, it's merely one implementation of a Unix-ish system. > You are tarring *BSD, Solaris, HPUX, and a bunch of others with a > failing that is not theirs. ...Hmmm, You're Right, Tom, no tarring intended beyond that deserved. Skipping the "is Linux a varriant of Unix" debate, I was apparently under the mistaken impression that at the very least HPUX and Solaris share this OOM Killer -ahem- feature as folks made comments to that effect on one of the PG lists a few months ago - or, perhaps I simply misread/misunderstood. Meanwhile, it's a very useful question to ask what the most reliable platforms are to run your production Postgres installations on, though it deserves its own thread, rather than treading on a cross-db-same-server dialogue. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Any Plans for cross database queries on the same server?
On Tue, 30 Jan 2007, Mark Walker wrote: > > I don't know. My customers expect 24/7 reliability. They expect to be > able to access their info anywhere in the world over a variety of > different devices. I can remember times when people would just go home > because computer networks were down. I haven't seen that happen in a > long time. ...Back in 1986, Cheryl Healy and I took on running Polaroid's corporate systems "24 X 7" - and we worked hard to make it "24 X 7 X 365.24". Shortly thereafter - while still working with Cheryl, Angel Vila, Chris Boerner and I took on running Bellcore's 800 telephone network full time also - our success was measured how few minutes/seconds there was any lost business at all on an annual basis. (Bellcore was previously known as AT&T Bell Laboratories.) If you made an 800 number based call from '86 to '89, the systems I managed for Bellcore helped place that call. ... I could go on. I've worked in the "always up" community a long time now and have worked with/for more corporations in this capacity than nearly anyone you might find - mostly very large, well known companies. My observation is that we have a real shortage of quality operating systems today, and what few exist/remain don't enjoy much market share because they're not based on Unix, so they're largely missing out on the Open Source activity. What may be worse, young people who don't know any better are sometimes told/taught not to bother with anything over five years old as it's antiquated so they don't ever find out that things could be better - and once were. (Example, anyone who thinks "man pages" are great has obviously got a very limited experience from which to base their opinion!) ... As a practical matter today we mostly have a choice of Windows or some flavor of unix, neither of which are great. That would be very different in my opinion if only Unix didn't have this asenine view that the choice between a memory management strategy that kills random processes and turning that off and accepting that your system hangs is a reasonable choice and that spending a measily % of performance in overhead to eliminate the problem is out of the question. Asenine, I tell you. Meanwhile, what Operating Systems ARE _today_ reliable choices upon which to run your Postgres datababse engine? ...BTW, McDonalds in Paris?! -smile- Just make sure you order Freedom Fries! Richard > > Maybe that's just my experience with my customers. I have seen signs of > dysfunctional computer systems lately. I was in a fast food restaurant > in San Francisco a few months back and they were manually taking > orders. I think the only reason they stayed open was because the owner > was there. Last summer a McDonald's in Paris next to the hotel my > family was staying at shut down because their computer system was down. > It ticked me off because we ended up eating at some pricey cafe next > door. I guess I'm a typical dumb American, traveling all the way to > Paris to eat at McDonald's. > > > Richard Troy wrote: > > On Tue, 30 Jan 2007, Mark Walker wrote: > > > >> LOL, I remember those days. "Uh, can you hold on? My computer just > >> went down." or "you need to fill out form 1203-B, send us $25 and we'll > >> get you the information you need in six weeks." Just kidding, but > >> certainly reliability standards and information demands are much higher > >> these days, aren't they? > >> > >> > > > > "Reliability standards ... higher these days?" > > > > -har-har-har!- That's a good one! > > > > Sure, in terms of bits moved/processed between hardware failures, things > > have much improved, but I can't help but think if what a joke it is that > > favored operating systems think it's OK to run out of memory for their own > > activity and randomly kill processes so they don't hang! HAH! Some > > Reilability. And people think this is a Good Thing (tm) because 1% of > > overhead was saved! > > > > > > Sure wish the Open Source OS people would get a clue; paying a percent or > > so for reliability pays for itself thousands of times over and most > > people, if knowledgeable, would choose to spend the overhead to have a > > system that really is reliable. > > > > > > > > Richard > > > > > > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Any Plans for cross database queries on the same server?
On Tue, 30 Jan 2007, Mark Walker wrote: > > LOL, I remember those days. "Uh, can you hold on? My computer just > went down." or "you need to fill out form 1203-B, send us $25 and we'll > get you the information you need in six weeks." Just kidding, but > certainly reliability standards and information demands are much higher > these days, aren't they? > "Reliability standards ... higher these days?" -har-har-har!- That's a good one! Sure, in terms of bits moved/processed between hardware failures, things have much improved, but I can't help but think if what a joke it is that favored operating systems think it's OK to run out of memory for their own activity and randomly kill processes so they don't hang! HAH! Some Reilability. And people think this is a Good Thing (tm) because 1% of overhead was saved! Sure wish the Open Source OS people would get a clue; paying a percent or so for reliability pays for itself thousands of times over and most people, if knowledgeable, would choose to spend the overhead to have a system that really is reliable. Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 1: 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: [GENERAL] Any Plans for cross database queries on the same server?
> On 01/30/07 14:41, Tony Caduto wrote: > > Mark Walker wrote: > >> It's sort of a matter of taste, but there are lots of people who like > >> to keep there logic on the server or at least within sql statements, > >> so there's probably a good sized market that your not reaching if you > >> ignore it. > >> > > That is a good point, I and many developers I know like to keep all the > > business logic on the server in stored procedure and functions and > > having this ability as a native part of Postgresql would be a huge > > advantage. > > DBlink is a decent workaround,but it becomes a pain having to wrap > > everything with the dblink syntax, plus there is a little bit of > > overhead involved creating a connection over TCP/IP to run a query on > > the same server. DBlink is great when you need to connect to a > > different server though. "Business logic on the server" - heh. If you want to know where all such ideas came from, think cynically. ...Originally, back in the day, the goal of creating "stored procedures", in particular, and aiding and abeting features like "triggers", had nothing to do with performance or clean architectures, rather the DBMS vendors figured this was a good way to trap customers into only being able to use their database engine. The more DBMS-engine-unique features a customer used the more expensive it would be for them to switch to another DBMS engine. The lack of standards regarding such "business logic" is precisely because the vendors didn't want portability. 'Course, in a mature market (like the RDBMS) this mostly benefits the largest vendors as gaining market share requires customers to convert. And so today we have companies like ANTs Software absorbing the costs of porting such features to their ANTs Data Server - last I heard they'd do the conversion for free. These days with good open source choices, things are a bit different, but that doesn't mean it's always good to go hog wild with any particular tool set just because you can. Sometimes people over-use engine-side features, forgetting that there are nearly always more cycles available on clients than servers... Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Password encryption method
On Mon, 22 Jan 2007, Bruno Wolff III wrote: > On Mon, Jan 22, 2007 at 20:25:48 +0100, > Bertram Scharpf <[EMAIL PROTECTED]> wrote: > > > > What I want to do is the following: > > > > 1. Login in from a program on a client as a particualar user. > > For this case you shouldn't need to do anything tricky as long as the user > is login in as themselves. Just prompt the user for their password and use it > when you open a connection to the database. If you are trying to have the > program login without the user being able to steal or borrow the credentials, > then you have a serious design flaw. I'm quite certain I missed the start of this thread, but just looking at the above paragraph as it stands: Design flaw? Perhaps an _incomplete_ design, but it's only a design flaw if not finished off properly. One way to do this cleanly is to use a program that has the suid bit set so it runs as the program's file owner (optionally group), and this program accesses the password and provides the database access. Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Spam from EnterpriseDB?
On Fri, 19 Jan 2007, Guy Fraser wrote:
> > Josh, under the law, that's not spam. Individually written emails are
> > never spam even if they may be "unsolicited sales material." So, rest
> > assured.
> >
> > Richard
> >
> You are oh so wrong in so many ways.
>
> SPAM is a term used for unsolicited email of any kind be it UCE
> {unsolicited commercial email}, UBE {unsolicited bulk email} or
> anything else that is unsolicited and sent to a large number of
> individuals or cross posted to a number of mailing lists and or
> news groups.
Guy,
No, by law, I'm correct, though it appears you've misread my post.
There's evidence you've misread what I wrote when you say, "sent to a
large number of individuals". When you sit down and author a letter to
_someone,_ "an individual", it's not spam. Note I didn't say "a large
number of individuals," I said "individually written," meaning, to one
person. ...I thought my writing was plain enough, but I guess English is
flexible enough to always provide room for misunderstanding...
BTW, this is a question of a legal definition of terms, not general use by
a community. Whatever the community thinks is irrelevent; there's law in
the U.S. regarding SPAM. I know not because I'm a lawyer and read the
statutes in question, but because I founded a company and as fearless
leader am responsible for knowing the rules; I consulted our corporate
council on the matter for definitive working rules in order to set our
corporate policy (in particular for Sales people as they're the biggest
risk to an organization in this regard).
Either way, I'm sure their embarassment on the matter is a substantial
penalty for the offending party as this community is their target customer
base, so your obvious anger can be at least somewhat satiated.
Richard
--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
[EMAIL PROTECTED], http://ScienceTools.com/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [GENERAL] Spam from EnterpriseDB?
On Thu, 18 Jan 2007, Joshua D. Drake wrote: > > > > Spam is spam. I don't care what they're selling. Anyone dumb enough to > > send spam in 2006 should be fired on the spot. > > That is a bit extreme. One persons SPAM is another persons interesting > information. Although I agree that the behavior in this particular > situation was a bit less than the average IQ score. > > If you are going to communicate with potential customers, especially as > SPAM have the integrity to do it yourself and take the heat yourself. > Don't use some off brand secondary service and pay them to spam for you. > > I send out email all the time to potentials. It is common practice but I > do it, directly as me. Josh, under the law, that's not spam. Individually written emails are never spam even if they may be "unsolicited sales material." So, rest assured. Richard > > Sincerely, > > Joshua D. Drake > > > > -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 1: 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: [GENERAL] index type for indexing long texts
> Aleksander Kmetec <[EMAIL PROTECTED]> writes: > > I'm looking for a solution for indexing long TEXT columns. We're currently > > using a HASH index, which can handle most > > situations, but every now and then we need support for even longer texts. > > > One solution would be to create a functional index which would only use the > > first N chars of mycol, but then we'd have > > to change several hundred occurences of "mycol = someval" with "(mycol = > > someval AND firstN(mycol) = firstN(someval))", > > as well as update some SQL generators... > > > That's why I'd be interested to know if there are any index types available > > which store only the first N chars or use > > some highly compressed form for storing index data, and then recheck any > > potential hits against the main table. And if > > something like that does not exist yet, how difficult would it be to > > construct such a solution out of many "spare parts" > > that come with PG? > Try moving where the hash takes place - ie, use your own hash function to create the key. RT -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.
On Thu, 11 Jan 2007, Tom Lane wrote: ...snip... > > (You know, of course, that my opinion is that no sane person would run a > production database on Windows in the first place. So the data-loss > risk to me seems less of a problem than the unexpected-failures problem. > It's not like there aren't a ton of other data-loss scenarios in that OS > that we can't do anything about...) > > regards, tom lane > PLEASE OH PLEASE document every f-ing one of them! (And I don't mean document Windows issues as comments in the source code. Best would be in the official documentation/on a web page.) On occasion, I could *really* use such a list! (If such already exists, please point me at it!) Thing is, Tom, not everybody has the same level of information you have on the subject... Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] TIMESTAMP WITHOUT TIME ZONE
> Richard Troy <[EMAIL PROTECTED]> writes: > > See my post from a few minutes ago, but simply put, time/date is at least > > as challenging as money or multibyte character. And, simply put, the > > Postgres implementation of timezone is INSUFFICIENT. > > Really? We do all the things you have listed, and more. AFAICS what > you have described is an outside-the-database reinvention of PG's > semantics for timestamp with time zone. > > regards, tom lane Hi Tom, thanks for the prompt reply... Not much time - just a few moments to reply and then I have to get on with my customer's deliverables... ...ISTM I took the meaning "TIMESTAMP WITH TIMEZONE" literally, while in reality the PG team has implemented the concept but "without timezone" in the database as a part of user data. I confess I never double checked the implementation details thereof as it sounds obvious you're including time zone data in the data stored by the server. Also, of the two RDBMSes in which I personally know the internal implementations of date/time, and of the ones I've talked with the engineers about, none of them get it right or even begin to get it right, so it never occured to me that Postgres would do so much better. Sounds like the PG team has once again thought about the problem from a different perspective and came up with a better answer. That said, nobody has yet assured me that when I give a timestamp I get it back unmolested. As you correctly recall, yes, Science Tools supports five RDBMSes and need to do so as cleanly and consistently as we can, and yes, it's pretty hard to do all the testing, given all the permutations. And, we're in the process of certifying both Ingres (which will make it, I'm sure) and ANTS (which might not). So, seven RDBMS choices... -shrug- I'd appreciate a clean yes/no; From a Java application, throught PG in both directions, the same timestamp comes back that was handed to the JDBC driver so long as it's stored in a "timestamp without time zone" attribute, nomatter neither where on earth the insert/update originates, nor where the select originates? Same bits, yes? Otherwise, "Houston, we've got a problem." Thanks again, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] TIMESTAMP WITHOUT TIME ZONE
On Wed, 13 Dec 2006, Richard Huxton wrote: > Randy Shelley wrote: > > I get different result if I query it from my workstation(US/Easter > > timezone) and from the server (GMT timezone). > > > A data type of timestamp without time zone should not do any > > conversions. The java.sql.Timestamp does not store any timezone info, > > just nano seconds from a date. Some where there is a timezone conversion > > happening. Why and how do I prevent it? > > Tom's stated the problem, but to expand a little. > > Your java.sql.Timestamp is an absolute point in time (presumably > measured from midnight 1970-01-01 GMT). Note that without the GMT there, > it would not be an absolute point in time since midnight in London was > different from midnight in New York. > > The "timestamp without time zone" is NOT an absolute point in time, it > is only meaningful for a single time zone. WRONG. It's a point in time that's meaningful to ME even if YOU can't tell where in the universe it's supposed to represent relative to any other point. > > The "timestamp with time zone" IS an absolute time, but it DOES NOT > record the timezone you enter. Rather, it is equivalent to your > java.sql.Timestamp. If you have a client in London and another in New OHMYGODYOUJUSTHAVETOBEWRONG!!! Let me get this straight; You're saying that you SUPPORT the idea of conversion being performed by the database (or it's cohort, the JDBC library in this case) when I, the author of an application using the data, depend on my database to give me back the data I gave it?! HORRIBLY BROKEN IF SO. > York, both will display the same absolute time but in their local time > zone. So, I might see 14:00+00 whereas a New-Yorker might see 08:00+05 > (if that's the right time-zone). You can ask for a specific time-zone > too (with AT TIME ZONE '...'). > > I think the biggest problem is that "with time zone" sounds like it's > storing a fixed time-zone when you insert a value. ...I missed the start of this thread but the CORRECT behavior for Postgres regarding TIMESTAMP WITHOUT TIMEZONE is to take a timestamp in whatever form _I_ care to give it and return it _exactly,_ unmodified in any way. See my post from a few minutes ago, but simply put, time/date is at least as challenging as money or multibyte character. And, simply put, the Postgres implementation of timezone is INSUFFICIENT. PLEASE tell me that when I give a PostgreSql server, through JDBC, a timestamp, stored in a TIMESTAMP WITHOUT TIMEZONE attribute, that it'll always give me back the _same_exact_bits_ as what I gave it! Anything else is horribly broken and is, to quote Tom Lane, "about as good a definition of corrupted data as I can think of." - with appologies to Tom, of course. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] TIMESTAMP WITHOUT TIME ZONE
Hi Tom, Randy, et al, I'm not fully caught up with my Readings In Postgres, but this post caught my eye and raised a concern... Tom Lane <[EMAIL PROTECTED]> wrote: > "Randy Shelley" <[EMAIL PROTECTED]> writes: > > The java.sql.Timestamp does not store any timezone info, just nano seconds > > from a date. > > One would hope that it's implicitly referenced to GMT, though, not some > free-floating value that means who-knows-what. > > I think your fundamental error is in using timestamp without time zone > in the database. Try with-time-zone if you want consistent results > across clients in different zones. > I sure hope there's no issue with using timestamp without timezone _anywhere_ in the PG world because, quite frankly, "timezone" just doesn't cut it. There are so many issues that I don't think I have time to justice to them here in a short email, but, just so we've all got some idea: First, you need at least minute, if not second offset from GMT to have anything like a comprehensive shot at "timezone." Hour-based time zones are simply insufficient. There are lots of places in the world with non-hour offsets from GMT. The second biggest issue is probably the plethora of "daylight savings time" schemes - and they change over time: notably within the last year, a U.S. community muffed handling such a chnage with their Canadian neighbors. And there are the timings of changes, too - do automated daemons know when the time changes? It's quite different in various parts of the world. Do you blindly follow your system clock? LOTS of questions here that are none of PG's business, but are vital to a production system always getting it right. Third, any presumption about when which version of a time should be valid is bound to cause major errors at some point or another. One can't just always hand the user a timestamp in local time on client ends because you don't know what kind of local processing they might wish to do outside of the database engine, not the least of which is the type of question, "was it after their business hours?" - a local-to-local question! Therefore, as a minimum, you _must_ provide transform functions, one to the other, and let the caller ask for what they wanted. This is particularly tricky when it comes to database join statements - did you give the query the GMT version, or local version?! -oy- The headaches this can cause, even among experts. We at Science Tools use "timestamp without timezone" as the basis of our handling our customer's data correctly. It's configurable, but by default all data going into a database is converted to GMT by our software, outside the database engine, unless explicitly directed otherwise. To handle the optionality of this, all join operations happen using what we call "database time", so if a db doesn't store in GMT for some reason, we still know what to do (for example, converting to the equivalent local time of the server). We track client's GMT offsets - stored in the db, of course - so we've got every client's offset data when needed, etc, etc, etc. ...I PRESUME there's nothing broken about "timestamp without timezone" within either the engine or the JDBC drivers, but I'd also caution to always punt on the question of whether or not someone should or shouldn't use Postgres' time zone feature. Perhaps a "for most people" qualifier, or, "when every user is in an hour-offset from GMT timezone", etc., but even then, multi-time-zone applications need to be VERY warry. Respectfully, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] Proposed ISO solution to Male/female
> > Male > > Female > > Hermaphrodite > > This read, "Intersexed" > > > Trans (MTF) > > Trans (FTM) > > Neuter > > > > and... I can't think of a seventh possibility. > > "Decline to state" ISO 5218 takes 22 pages to give us four oddly placed values for male, female, and two versions of null, "unknown" and "not aplicable." Interestingly, it doesn't include "declined to state." The values are as previously stated: 0 = unknown 1 = male 2 = female 9 = not aplicable As pointed out above, there really are more legitimate values. To track all of them and still be aproximagely ISO compatible, I propose the following. Based on the observation that ISO 5318 mathematically specifies male as odd and female as even, the y-chromosome containing sexes (which include hermaphrodites), shall be odd. This leaves unknown, as even, and perhaps neuter can be not aplicable, since we don't know. ... This does leave "declined to state" as a valid form of "null." >From this I propose the following: 0 = unknown 1 = male 2 = female 3 = hermaphrodite 4 = female to male transgender 5 = male to female transgender 6 = 7 = 8 = declined to state 9 = Neuter - Not applicable One could also move the blanks around like this, which might be useful: 0 = unknown 1 = male 2 = female 3 = 4 = female to male transgender 5 = male to female transgender 6 = 7 = hermaphrodite 8 = declined to state 9 = Neuter - Not applicable Hmmm... Easy to write the various functions making this a new datatype... Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Male/female
On Fri, 8 Dec 2006, Raymond O'Donnell wrote: > > Yes, the table is used only for humans; it's part of some > administrative software I'm writing for an educational institution, > and the primary purpose of the gender column is to help the users > cope with a problem new to the west of Ireland - the large influx of > immigrants from Africa, eastern Europe and elsewhere means that it's > no longer possible to tell a student's gender just from their > name! > > --Ray. Ray, darest I point out that that's never been possible in English anyway? There are dozens if not hundreds of androgenous names - Pat and Tracy come immediately to mind, and there are countless others! RT -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Development of cross-platform GUI for Open Source DBs
On Wed, 29 Nov 2006, Ritesh Nadhani wrote: > > Hello > > I have been working with wxWidgets and I didnt face a problem. What > specific thing were broken in wxWidgets for Windows? > > Ritesh PLEASE take this offline - it's not even close to Postgres related. Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Development of cross-platform GUI for Open Source DBs
On Sun, 26 Nov 2006, Ritesh Nadhani wrote: > > Well, sorry if my words were confusing. I was thinking of an MS SQL > Query Analyzer, SQLyog, PGAdmin kind of tool to start with which will > provide a basic admin tool initially. And based upon that > layer/architecture we will provide more advanced tools like query > builder etc. > > I think I jumped the boat far too quickly, I also meant a development > environment to be provided by this tool later on but come to think of > it, it is already provided by OpenOffice so we wont probably need to > think on that line. There's room for something other than what OpenOffice provides, but a morphed DB Admin tool certainly isn't it because they have very different goals. I, for example, would like a toolset that helps take the drudgery out of making a db-connected application and convert it into both/either a more traditional client/application-server and/or a web application. I'm sure there are a lot of people who'd like to see this, too, but these application-perspective based needs are _dramatically_ different from database admin needs. Combining them is bound to be more trouble than it's worth as they have virtually nothing in common. > So I guess, the tool that I have in mind is a database management > interface - something like Toad for Oracle (which probably everybody > knows). Toad? No, everybody doesn't know. But the idea of going for a cross-datrabase-platform db-admin tool is a fine one. Also, repeating for emphasis my brief and incomplete "differences list:" > > A few thoughts here; each db engine has its own; > > > > - sql dialect, dispite the best efforts of SQL92 et al. > > > > - sql query plan output mechanism and format > > > > - naming restrictions (some know from context what table/attribute names > > are while others absolutely demand reserved-words remain reserved, even > > when they'll never be found in a particular context) - presuming you want > > to provide, "works here but not there" advice. > > > > - system catalogs > > > > - index structures > > > > - transaction log semantics > > > > - lock management - presuming you wish to include a "which transaction has > > the lock" functionality > > > > - activity/error/security log systems - presuming you wish to provide > > error resolution assistance > > > > - maintenance tools suite, like Postgres' vacuum > > > > - backup and recovery suite > > > > Yes I know that. So we can make our architecture to be modular where > each db interface use its own most efficient way rather then a generic > way which would make things slow. And if a feature is not provided by > a DB, that option would be just turned off for that DB. > > My motivation for the idea comes from the plauggable engine support > that MySQL provides. OK, "pluggable," but please read my words carefully and get the hint: If you do _not_ provide features like accessing the query plans, finding lock holders to sort out deadlocks, and these other database-specific items listed above - and others I didn't list - you will NOT be providing functionality that's worth the time. Let me put it this way; Right now I have to support (at least) five RDBMSes: Postgres, Informix, Sybase, DB2, Oracle - and we're considering ANTS. The idea of a cross-dbms admin tool sounds great but is USELESS - not worth my time - if it doesn't address these every-day-in-production needs because, lets face it, I'll _still_ have to use those platform specific mechanisms - and if I have to access them _anyway,_ why bother with yet another tool that doesn't do the job? The answer is, it won't have the user base you're looking for. Seems to me, you need to get back to square one: What problem(s) are you trying to solve? And an answer that says, "Oh, all this DBMS admin stuff and - eventually! - an app builder too!" is not an answer I can believe as it's too ambitious, and not focused on any core user group. Good luck, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Development of cross-platform GUI for Open Source DBs
has > transformed itself into a highly powerful cross-platform GUI library > which when compiled gives the native look and feel of the host operating > system. This is something which other libraries like Qt, JAVA lack. > > More info about wxwidgets can be found at: http://www.wxwidgets.org. > > > Yet unnamed DB management environment > === > > I dont have the time nor the resources to do everything by myself. As I > see, there are too many things which are best distributed among > people/developers who are good at those specific things. E.g. I will > require good graphics designer to develop the icons for the tool, web > developer to keep the website updated, db specific veterans to best code > individual db management code etc. > > Also, it would be a great way to learn some programming and show it as > part of your undergraduate/graduate project development requirement :) > > Is it viable? > === > > I am not too big a fan of reinventing the wheel or work on a project > which will go bust in couple of years? So what I want is from you people > a little initial idea and discussion about such a tool. Is it viable? Is > it OK to develop such a tool? Will people use it? Because the distinctive features between RDBMSes I cited above - and others I didn't cite - change with time, you don't want to hard-code them. Nor, does it seem to me, do you wish to hard code which database engines are supported. Therefore, it's clear to me that you want to develop a way to support any new / new version RDBMS in a way that's easily extensible, or configurable, if you will. I think it's a lot harder to do than might sound. > > I am cross posting this to various db mailing lists as well as relevant > newsgroups to get maximum idea about it. You can also contact me > directly at [EMAIL PROTECTED] if you would be interested. Well, I think we expect you're still on our email list so you can receive replies, yes? Not everybody replies to both list and author separately. -shrug- > > Waiting for your comments. > > -- Ritesh All that said, I'd use such a tool if one were available... Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Counting records in a PL/pgsql cursor
On Fri, 3 Nov 2006, Merlin Moncure wrote: > > > > I can deal with materializing the resultset, but I want to get away from > > the loop-a-thousand-times-doing-plus-one... > > i dont think its possible. note that you can make a refcursor inside > your plpgsql function and pass it to an sql function which can do sql > cursor operations on it -- i think :-)..haven't tried it yet. > > merlin ...If you know your application well enough, you might get away with doing a select count() with the same where clause just before entering the cursor. It _could_ of course be wrong, though! OTOH, it would be much faster. If the only down-side is occasionally giving users an incorrect count, then perhaps call it a "row estimate", and let them marvel at how accurate the estimate is most of hte time! Good luck, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Is there anyway to...
On Thu, 2 Nov 2006, AgentM wrote: > > > > Just some commentary... This is exactly the sort of thing cron is > > for. Duplicating that functionality in the RDBMS would be silly > > IMO. I don't see why you could consider cron to be "dirty" for > > this application... > > I actually tried to come up with something for this. There are plenty > of good reasons to have some timer functionality in the database: > > 1) it makes regular database-oriented tasks OS portable > 2) your cron user needs specific permissions + authorization to > access the database whereas postgres could handle "sudo"-like > behavior transparently > 3) there are triggers other than time that could be handy- on vacuum, > on db start, on db quit, on NOTIFY > > Unfortunately, the limitation I came across was for 2). There is no > way to use "set session authorization" or "set role" safely because > the wrapped code could always exit from the sandbox. So my timer only > works for db superusers. > > -M ...This type of need is exactly what custom written daemons are for. They're surely database and OS portable (or can be, at least), there's no need for any super-user capability of any kind, you can use any kind of trigger you like, and there's no permission leakage problem, either... I guess all you need is functioning nohup capability (which Windows systems may have trouble with, I don't know). Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Modifying SQL parser with extensions?
Matthias, what you want might be a type of collation sequence. You should be able to code that within Postgres, I'd think, but I wouldn't think that passing arguments as comments is appropriate. RT On Sun, 29 Oct 2006, Matthias Lüdtke wrote: > Date: Sun, 29 Oct 2006 18:26:30 +0100 > From: Matthias Lüdtke <[EMAIL PROTECTED]> > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Modifying SQL parser with extensions? > > > Richard Troy wrote: > > Our package lets you pass individual statements or entire files full > > of SQL with embeded comments as it's not that uncommon among SQL > > dialects - they're just stripped out before getting to the engine, as > > Alvaro suggested. > > Unfortunately I need the information in the statement to sort the result > set in a certain way later on. Sorry, I should have mentioned that from > the beginning. > > This whole thing I want to implement was already written as a proxy JDBC > driver - from parser to result sorter - and works quite fine. I am now > investigating if it's possible to implement it directly in an RDBMS, > i.e. PostgreSQL. > > Regards, > Matthias > > -------(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Modifying SQL parser with extensions?
On Sun, 29 Oct 2006, Alvaro Herrera wrote: > > Matthias Lüdtke wrote: > > Hi everyone, > > > > I am searching for the easiest way to let PostgreSQL parse a special > > dialect of SQL. The dialect I want to parse augments common SQL in a way > > that enables expressions within a WHERE clause to be annotated and is > > thus not compatible with the standard SQL syntax anymore. > > No, there's no mechanism for that. You'd have to preprocess the query > before passing it to PostgreSQL. > Right, no mechanism within PostgreSql, however there are packages that can do it for you. I don't know of any in the OpenSource world, but my company, as but one example, has software that lets you run any dialect of SQL against nearly any RDBMS - unique and embeded features excluded (they're just passed through). Our package lets you pass individual statements or entire files full of SQL with embeded comments as it's not that uncommon among SQL dialects - they're just stripped out before getting to the engine, as Alvaro suggested. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] [SQL] Can we convert from Postgres to Oracle !!???
On Thu, 26 Oct 2006, Jim C. Nasby wrote: > Date: Thu, 26 Oct 2006 22:06:30 -0500 > From: Jim C. Nasby <[EMAIL PROTECTED]> > To: Devrim GUNDUZ <[EMAIL PROTECTED]> > Cc: Sandeep Kumar Jakkaraju <[EMAIL PROTECTED]>, > pgsql-general@postgresql.org, [EMAIL PROTECTED], > pgsql-sql@postgresql.org > Subject: Re: [GENERAL] [SQL] Can we convert from Postgres to Oracle !!??? > > On Sun, Oct 22, 2006 at 12:03:38AM +0300, Devrim GUNDUZ wrote: > > On Tue, 2006-10-17 at 14:21 +0530, Sandeep Kumar Jakkaraju wrote: > > > Can we convert from Postgres to Oracle !!??? > > You can also run our software and get Oracle syntax for 1/25th the cost. > ...And if we're making commercial plugs here - Is that OK? - another option is to use my company's software to be able to write your apps with nearly any dialect of Sql and run it against nearly any RDBMS engine. (Oracle, Postgres, Sybase, Db2 and Informix are presently certified.) So, you write once, run anywhere - unique features and embeded code not withstanding, of course. With this toolset, you can also have an app that talks to multiple database types simultaneously. The system includes the option to journal on either client or server side and the journals can be played back against a database of a different RDBMS type - including blob and clob support, and time support with minute offset from GMT (developed for scientific applications). Only two hitches; the library that does this magic is written in Java, and, it's not free. -smile- Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Postgres history and the 30th Anniv. of Ingres, gathering at UCB...
ty Ingres team continued on. In an effort to keep leading the way, Mike's UCB team moved into expanding datatypes. After not very long, they had added "Universal Data Types" to University Ingres, along with functions and operators needed to make them work. This was quickly adopted by the commercial Ingres team, then known as Ingres Corporation. I really don't recall just what the timing was but I think the Berkeley team, after UDT development but before commercialization, realized that they could rewrite University Ingres to use the whole set of UDT concepts throughout the project, and they felt it deserved a new name - I think this also coincided with a switch in grant money... Since it was now "after Ingres", someone came up with the name Postgres, and it stuck. I vaguely recall seeing t-shirts with the new name in 1992 - "PostgreSql", "Postgres the Sequel", they proclaimed. In 1993, as I recall, one of my reports at Ingres, Paul Brown, left my group to join Mike's team at UCB, and the following year, after Ingres was bought by Computer Associates, Mike convinced me to lead a research team for him at UCB, working right along side the Postgres folks. However, by the time the bureaucratic wheels turned enough for Mike to hire me as a researcher with managerial authority, the Postgres team was already winding down. I think they had grant money through to September or November of '94, but in any case, Paul was the last Postgres-hire (a paid researcher), and, thankfully, left them to join my team immediately - along with Turing Award-winner Jim Gray, among others. I lost Paul again when he jumped ship about a year later to go to Illustra, the company Mike founded for the commercialization of Postgres. Within a handfull of months after Paul joined them, Illustra was bought by Informix, who tried to integrate Illustra with their RDBMS. In short, I think their integration lost the best of Postgres by keeping the worst parts of both systems, if you were to ask me, but either way Informix went on to be bought by IBM. (Meanwhile, I kept on working for Mike at UCB, later getting my own grants, and finally commercializing my own work by founding Science Tools...) So, here it is all these years later. Someone else will have to step in and tell us how this Postgres Open-Source movement got started, if any of the folks had connections to UCB, the original Postgres team, and so forth. I can't tell you anything about that. What I can add, however, is that there will be a public lecture given by Michael Stonebraker, Eugene Wong, Peter Kreps and Jerry Held regarding their paper "The Design and Implementation of INGRES" on Wednesday, Nov 29th, at Soda Hall, UC Berkeley, with reception to follow immediately thereafter. More information and (free) registration is here: http://www.eecs.berkeley.edu/IPRO/INGRES30/ I think you have until the first of November to register. Below are some emails that you may find of some interest on this same subject. Note that the Ingres community, some twelve plus years after the company's demise, still hangs to gether as Ex-Ingres - "Ingres Corporate Culture without the corporation!" In closing, I'd very much enjoy meeting folks from the PostgreSql team, especially the core members. You'll find me at this talk/reception - hope to see you there. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ -- From: elein To: exingres at exingres.org Subject: [ExIngres] Invitation to Stonebraker/Wong/Held/Kreps lecture at UCB I received this message from Dr. Paula Hawthorn who is involved in setting up the endowment fund mentioned below. She asked me to forward it to this list since the subject may be near and dear to the database fans among us as well as the people who worked at INGRES early on. Please feel free to forward the message to others who may be interested. It will be great to give the *original* INGRES some credit it deserves as well as to give a hand to the next generation of database geeks. --elein elein at varlena.com Dear Friends: This year marks the 30th anniversary of the publication of the paper "The Design and Implementation of INGRES". To mark this occasion, Cal EECS is inviting the authors, Michael Stonebraker, Gene Wong, Jerry Held and Peter Kreps to give a Distinguished Lecture this fall. You are invited to both the lecture and the reception that will follow. The lecture will begin at 4PM on Wednesday, Nov. 29, the reception shortly after. If you are planning to attend, it is important that you register for the reception by October 1. For details, and to register, go to http://www.eecs.berkeley.edu/IPRO/INGRES30/ At the reception, Mike & Gene's students & colleagues will be announcing the UC Berkeley College of Engineering Mike Stonebraker-Eug
