Thread: Future of PostgreSQL
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish a PostgreSQL book
With these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.
My big question is, what new challenges will we face as we become more
popular?
Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 25 Dec 1999, Bruce Momjian wrote: > Consider this: > > The stock market going crazy over Linux stocks > Interbase users are considering moving en-mass to PostgreSQL > Publishers are crawling all over each other to publish a PostgreSQL book > > With these signs, it is possible we may be _very_ popular in the near > future. I am not sure this will happen, but I didn't think this would > happen to Linux. The worst thing we could do is to intentionally try to stay less than popular. There's a reason Linux is taking off and *BSD isn't really, and it's not technology. (Sorry, Marc.) > > My big question is, what new challenges will we face as we become more > popular? > > Do we have the proper license? I know this has the possibility of > opening up a GPL vs. BSD slugfest. However, I will not let such a > discussion get out of control. > > One thing we should definitely attempt to do before 7.0 is write our own license or at least our own copyright in addition to the BSD license, since none of us (?) actually work at UCB. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> On Sat, 25 Dec 1999, Bruce Momjian wrote:
>
> > Consider this:
> >
> > The stock market going crazy over Linux stocks
> > Interbase users are considering moving en-mass to PostgreSQL
> > Publishers are crawling all over each other to publish a PostgreSQL book
These three items represent three good signs:
Commercial success of a related technology
Increased user interest
Increased commercial interest
BTW, I forgot to mention that my web page at
> >
> > With these signs, it is possible we may be _very_ popular in the near
> > future. I am not sure this will happen, but I didn't think this would
> > happen to Linux.
>
> The worst thing we could do is to intentionally try to stay less than
> popular. There's a reason Linux is taking off and *BSD isn't really, and
> it's not technology. (Sorry, Marc.)
I think everyone can agree with that, including Marc.
>
> >
> > My big question is, what new challenges will we face as we become more
> > popular?
> >
> > Do we have the proper license? I know this has the possibility of
> > opening up a GPL vs. BSD slugfest. However, I will not let such a
> > discussion get out of control.
> >
> >
>
> One thing we should definitely attempt to do before 7.0 is write our own
> license or at least our own copyright in addition to the BSD license,
> since none of us (?) actually work at UCB.
We certainly have the power to add a license of our own. BSDI has done
this, as well as many other companies. I don't want to wait until
things get very busy and then try to address these issues. We may
decide we don't want to do anything, but I would like to decide that
now.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 25 Dec 1999, Bruce Momjian wrote:
>> On Sat, 25 Dec 1999, Bruce Momjian wrote:
>> The worst thing we could do is to intentionally try to stay less than
>> popular. There's a reason Linux is taking off and *BSD isn't really, and
>> it's not technology. (Sorry, Marc.)
>
>I think everyone can agree with that, including Marc.
As long as it's not like "*BSD has better tech than Linux" kinda thing.
>We certainly have the power to add a license of our own. BSDI has done
>this, as well as many other companies. I don't want to wait until
>things get very busy and then try to address these issues. We may
>decide we don't want to do anything, but I would like to decide that
>now.
I don't quite understand why you think that a license change is neaded.
One of the things that made me into PostgreSQL was exactly it's license.
-------------------- Jose Miguel Pereira Tavares --------------------
Talking much about oneself can also be a means to conceal oneself.
-- Friedrich Nietzsche
> >We certainly have the power to add a license of our own. BSDI has done > >this, as well as many other companies. I don't want to wait until > >things get very busy and then try to address these issues. We may > >decide we don't want to do anything, but I would like to decide that > >now. > > I don't quite understand why you think that a license change is neaded. > One of the things that made me into PostgreSQL was exactly it's license. I am not saying we need one. I am just asking. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote: > My big question is, what new challenges will we face as we become more > popular? The 3 greatest technical/engineering challenges: 1) system reliability & recoverability, 2) system reliability & recoverability, and 3) system reliability and recoverability. The masses won't stay long if the system won't stay up, isn't easy to diagnose by non-experts, or cannot be easily restored from backups without significant data losses. New functionality is great, but a system that won't stay up consistently is approaching worthlessness for mission-critical 24x7 applications. And if the masses leave because of system reliability problems, you can be very, very certain about what they will tell their friends and coworkers. Cheers, Ed Loehr
> Bruce Momjian wrote: > > > My big question is, what new challenges will we face as we > become more > popular? > > The 3 greatest technical/engineering challenges: 1) system > reliability & recoverability, 2) system reliability & recoverability, > and 3) system reliability and recoverability. The masses won't > stay long if the system won't stay up, isn't easy to diagnose > by non-experts, or cannot be easily restored from backups without > significant data losses. New functionality is great, but a > system that won't stay up consistently is approaching worthlessness > for mission-critical 24x7 applications. And if the masses > leave because of system reliability problems, you can be very, > very certain about what they will tell their friends and coworkers. And we don't have a problem in this area, do we? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote: > > Bruce Momjian wrote: > > > > > My big question is, what new challenges will we face as we > > become more > popular? > > > > The 3 greatest technical/engineering challenges: 1) system > > reliability & recoverability, 2) system reliability & recoverability, > > and 3) system reliability and recoverability. The masses won't > > stay long if the system won't stay up, isn't easy to diagnose > > by non-experts, or cannot be easily restored from backups without > > significant data losses. New functionality is great, but a > > system that won't stay up consistently is approaching worthlessness > > for mission-critical 24x7 applications. And if the masses > > leave because of system reliability problems, you can be very, > > very certain about what they will tell their friends and coworkers. > > And we don't have a problem in this area, do we? Please tell me you're kidding. Cheers, Ed Loehr
> > > system that won't stay up consistently is approaching worthlessness > > > for mission-critical 24x7 applications. And if the masses > > > leave because of system reliability problems, you can be very, > > > very certain about what they will tell their friends and coworkers. > > > > And we don't have a problem in this area, do we? > > Please tell me you're kidding. We don't have roll-forward logging until 7.1, and require vacuum regularly. Other than that, I don't know of any major issues. Reliability has always been of primary importance. We wouldn't be where we are today without reliability. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 25 Dec 1999, Bruce Momjian wrote: > My big question is, what new challenges will we face as > we become more popular? Plug-in Oracle 7 compatibility.
> > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > My big question is, what new challenges will we face as > > we become more popular? > > Plug-in Oracle 7 compatibility. I believe we are adding Oracle compatibility as possible. We are working on write-ahead log, long tuples, foreign keys, and outer joins. Anything else? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 25 Dec 1999, Bruce Momjian wrote: > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > My big question is, what new challenges will we face as > > > we become more popular? > > > > Plug-in Oracle 7 compatibility. > > I believe we are adding Oracle compatibility as possible. We are > working on write-ahead log, long tuples, foreign keys, and outer joins. > Anything else? How about an SQL*Net listener... this would make PostgreSQL plug-n-play. It could even be a proprietary product, thus allowing VC's to fund it. It's a bit hard to justify changing ODBC settings on 30+ apps on a few (hundred) thousand PC workstations; some with hardcoded ODBC "ORA7.DLL" settings... Why? Oracle is going to be shutting down Oracle 7 support soon, forcing the upgrade to Oracle 8. This will leave hundreds (thousands accross the industry?) of applications stranded, and not alot of money to re-write/re-deploy/re-test them. Just a thought... at every big company I've been with, this has been a sore spot. It could also potentially be a good consulting revenue stream for Marc's group. Best, Clark
At 06:25 PM 12/25/99 +0100, Peter Eisentraut wrote: >On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > Consider this: > > > > The stock market going crazy over Linux stocks > > Interbase users are considering moving en-mass to PostgreSQL > > Publishers are crawling all over each other to publish a > PostgreSQL book > > > > With these signs, it is possible we may be _very_ popular in the near > > future. I am not sure this will happen, but I didn't think this would > > happen to Linux. > >The worst thing we could do is to intentionally try to stay less than >popular. There's a reason Linux is taking off and *BSD isn't really, and >it's not technology. (Sorry, Marc.) I don't think the *BSD's have intentionally tried any such thing. You could possibly have picked up these vibes from certain members of the Open BSD camp, but I wouldn't extend them to encompass the *BSD community at large. (And I wonder if I should comment about how Linux people are migrating to the *BSD camps in droves.... But I guess it'd be best to just let it slide ;-o) > > > > My big question is, what new challenges will we face as we become more > > popular? > > > > Do we have the proper license? I know this has the possibility of > > opening up a GPL vs. BSD slugfest. However, I will not let such a > > discussion get out of control. > > > > > >One thing we should definitely attempt to do before 7.0 is write our own >license or at least our own copyright in addition to the BSD license, >since none of us (?) actually work at UCB. I come to pgsql from MySQL. I've not done much of anything with it yet really, so I should probably keep my mouth shut. But I thought you might be interested in my perspective. And, after all, you did ask... My hands on experience with pgsql is minimal, but follows is the sense I get from the larger community and having lurked on this list for a bit. The primary "feature" that has me looking at pgsql again is the license. I like MySQL. The MySQL community is great. I don't like their license, however, and feel pretty strongly about it. I would counsel against developing your own. Why reinvent the wheel unless you've got some special agenda that requires it? I prefer the more liberal BSD, but GPL is fine. Transaction support is also nice, but secondary to license issues. There are mysql workarounds in for the absence of transaction support, but it's hard to get around the license and still be honest. I would hope that future development continues to focus on reliability, functionality, and speed. Your work will then speak for itself and more people will adopt pgsql. I initially ruled it out because of reliability and speed concerns. The past year has seen much improvement in these areas, enough to have piqued my interest once again. The *perception* remains, however, that pgsql still leaves a bit to be desired in the areas of reliability and maintainability. This needs to be remedied. Like I said, progress has been mad, but it appears pgsql isn't quite out of the woods yet. Well, there's my $0.02. Thanks for your indulgence. Regards-- Ken
Bruce Momjian wrote: > We don't have roll-forward logging until 7.1, and require vacuum > regularly. Other than that, I don't know of any major issues. > Reliability has always been of primary importance. We wouldn't be where > we are today without reliability. Here's an idea: How about a web poll on www.postgresql.org to assess the current state of affairs from the user's perspective? That would have several advantages. First, it's pretty easy to do. Second, if there are, in fact, few or no outstanding major reliability issues, that's good to know and provides firmer footing for feature planning (also great marketing fodder). Third, it could provide a quantitative baseline for future comparisons, helping everyone to get warm fuzzies when measurable improvement appears. Most importantly, it would provide an opportunity for corrective action if by chance current assumptions are wrong. Cheers, Ed Loehr
On Sat, 25 Dec 1999, Clark C. Evans wrote: > > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > My big question is, what new challenges will we face as > > we become more popular? > > Plug-in Oracle 7 compatibility. I know we have (and have for awhile) a good deal of Oracle compatibility...what do you mean by 'Plug-In Oracle 7 compatibility'?
On Sun, 26 Dec 1999, Ed Loehr wrote: > Bruce Momjian wrote: > > > We don't have roll-forward logging until 7.1, and require vacuum > > regularly. Other than that, I don't know of any major issues. > > Reliability has always been of primary importance. We wouldn't be where > > we are today without reliability. > > Here's an idea: How about a web poll on www.postgresql.org to assess > the current state of affairs from the user's perspective? That would > have several advantages. First, it's pretty easy to do. Second, if > there are, in fact, few or no outstanding major reliability issues, > that's good to know and provides firmer footing for feature planning > (also great marketing fodder). Third, it could provide a quantitative > baseline for future comparisons, helping everyone to get warm fuzzies > when measurable improvement appears. Most importantly, it would > provide an opportunity for corrective action if by chance current > assumptions are wrong. Feel like writing it? I can provide you with an account, and database access, if you want to work on this sort of thing?
> I believe we are adding Oracle compatibility as possible. We are > working on write-ahead log, long tuples, foreign keys, and outer joins. > Anything else? Yes, earlier in the year I was trying to migrate from Pervasive SQL to posgtres and came to a screaming halt when it wouldn't do a large view. Exceeded some sort of internal buffer or rule area. I dont recall the details, although the mail archive will have it. I think that was going into the V7 todo list. And of course the perenial full (rowset returning) stored procedures with parameters. Regards John
Hi, > > The 3 greatest technical/engineering challenges: 1) system > > reliability & recoverability, 2) system reliability & recoverability, > > and 3) system reliability and recoverability. > > And we don't have a problem in this area, do we? At the moment, not realy, but a few things would be VERY nice: - No need for a complete dump/restore on an major upgrade - A pg_dump that ALWAYS can make a dump that can be restored without editing it first (When a user had the access to create databases, creates some, and that access is removed, the dump can't be restored anymore because it creates the user without the rights to create databases, but somewhat later tries to create a database with that user. I hope you understand this... :) I now create all databases by hand as the superuser, and set the datdba myself. - A dump program that can dump/restore large objects. Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot without any big problems. Just some ideas to make it easier for the administrator. And of course, thanks for all the work on PostgreSQL that makes it what it is now, and a Merry Cristmas! Sander Steffann.
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > I believe we are adding Oracle compatibility as possible. We are > > working on write-ahead log, long tuples, foreign keys, and outer joins. > > Anything else? > > Yes, earlier in the year I was trying to migrate from Pervasive SQL to > posgtres and > came to a screaming halt when it wouldn't do a large view. Exceeded some > sort of internal buffer > or rule area. I dont recall the details, although the mail archive will have > it. > > I think that was going into the V7 todo list. We have a plan for large tuples, and Jan is working on it. I am pushing to see if we can get it in 7.0, but it may have to wait for 7.1. Let's see what happens. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > > > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > My big question is, what new challenges will we face as > > > we become more popular? > > > > Plug-in Oracle 7 compatibility. > > I believe we are adding Oracle compatibility as possible. We are > working on write-ahead log, long tuples, foreign keys, and outer joins. > Anything else? tablespace support ( which isnt a trivial task ), groups ( pgsql has this sort of functionality already, but i dont think its to the extent that Oracle does ), some additional grants ( 'grant connect to' ), 'alter table <table> add constraint <constraint definition>'... tablespace support would put pgsql soooo far ahead of most other rdbmses. --- Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org "I've learned that you cannot make someone love you. All you can do is stalk them and hope they panic and give in."
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi, > > > > The 3 greatest technical/engineering challenges: 1) system > > > reliability & recoverability, 2) system reliability & recoverability, > > > and 3) system reliability and recoverability. > > > > And we don't have a problem in this area, do we? > > At the moment, not realy, but a few things would be VERY nice: > - No need for a complete dump/restore on an major upgrade pg_upgrade allows us to do that _when_ we don't change the on-disk format of the data. We did not do that in 6.4, but did do that in 6.5. I think 7.0 also will have a change. Not much we can do about that. When we stop adding major features, pg_upgrade can be used for every release. :-) > - A pg_dump that ALWAYS can make a dump that can be restored without editing > it first > (When a user had the access to create databases, creates some, and that > access is removed, the dump can't be restored anymore because it creates the > user without the rights to create databases, but somewhat later tries to > create a database with that user. I hope you understand this... :) I now > create all databases by hand as the superuser, and set the datdba myself. We are working on dumping in OID order. That should solve that problem. We only came up with that solution recently. > - A dump program that can dump/restore large objects. > > Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot > without any big problems. Just some ideas to make it easier for the > administrator. We are going to do very long tuples in 7.0 and 7.1. This may make large objects obsolete. > > And of course, thanks for all the work on PostgreSQL that makes it what it > is now, and a Merry Cristmas! Oh, yes, Merry Christmas to everyone too. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Marc G. Fournier" wrote: > On Sun, 26 Dec 1999, Ed Loehr wrote: > > > Bruce Momjian wrote: > > > > > We don't have roll-forward logging until 7.1, and require vacuum > > > regularly. Other than that, I don't know of any major issues. > > > Reliability has always been of primary importance. We wouldn't be where > > > we are today without reliability. > > > > Here's an idea: How about a web poll on www.postgresql.org to assess > > the current state of affairs from the user's perspective? That would > > have several advantages. First, it's pretty easy to do. Second, if > > there are, in fact, few or no outstanding major reliability issues, > > that's good to know and provides firmer footing for feature planning > > (also great marketing fodder). Third, it could provide a quantitative > > baseline for future comparisons, helping everyone to get warm fuzzies > > when measurable improvement appears. Most importantly, it would > > provide an opportunity for corrective action if by chance current > > assumptions are wrong. > > Feel like writing it? I can provide you with an account, and database > access, if you want to work on this sort of thing? Sure. Quite swamped right now, but should be able to have something in January. Please set up an account with DB access... Cheers, Ed Loehr
At 10:27 PM 12/25/99, Bruce Momjian wrote: >[snip] > > Plug-in Oracle 7 compatibility. > >I believe we are adding Oracle compatibility as possible. We are >working on write-ahead log, long tuples, foreign keys, and outer joins. >Anything else? Replication would be nice, or some other form of clustering so the load can be easily split among multiple PostGres servers. My personal pet peeves are the difficulty of the backup/restore process (well, it's not really difficult, it just takes a while) and the 8k query limit. Also, the ability to restrict CREATE [ TABLE | INDEX | SEQUENCE ...] would be nice.
On Sun, 26 Dec 1999, Marc G. Fournier wrote: > On Sat, 25 Dec 1999, Clark C. Evans wrote: > > Plug-in Oracle 7 compatibility. > > I know we have (and have for awhile) a good deal of Oracle > compatibility...what do you mean by 'Plug-In Oracle 7 compatibility'? Plug in Oracle compatibility would mean being able to drop a PostgreSQL server as a replacement to an Oracle server and not having to reconfigure any clients, rewrite any SQL, and basically not even know that the database server has been changed. I personally don't think that 100% drop-in Oracle Compatibility is a good goal -- see Philip Greenspun's Oracle Tips page at http://photo.net/wtr/oracle-tips.html. He also has some real good points about LONG types and oracle CLOBs -- tips that are very worth reading, IMO. I want my long texts to be transparent to my tcl code -- I want to index them for speed, and I want full functionality -- I don't want CLOBS (a takeoff on Postgres/Illustra large objects, IIANM). .... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Well, I like to see replication, at least snapshot type, and later merge type... Snapshot should allow load balancing while querying db, and allow distributed web/db server. The replication should work over LAN/WAN and snailmail. The replication shouldn't be dependent of a transport/network config. Also, some XML import/export routine to import and export to tables... Relationships should be hardcoded in the database. Also, i'm not sure if it is part of current version, but we should be able to alter a field definition in a table without having to drop the table... Franck franck@sopac.org.fj
On Sun, 26 Dec 1999, Bruce Momjian wrote:
> > - A dump program that can dump/restore large objects.
> >
> > Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot
> > without any big problems. Just some ideas to make it easier for the
> > administrator.
>
> We are going to do very long tuples in 7.0 and 7.1. This may make large
> objects obsolete.
You can try for LO dump:
ftp://ftp2.zf.jcu.cz/users/zakkr/pg/pg_dumplo-0.0.3.tar.gz
I write this program for my private project, but I can continue in this
program development if it is interesting for more PG's uses. (Or add it to
contrib?)
..But as Bruce say, LO API is obsolete. But we don't forget: now exist
application which use LO and rewrite this app. to standard-tuple version
will of long duration - good LO support must be in more next PgSQL
versions too.
Karel
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
On Sun, 26 Dec 1999, Howie wrote:
> On Sat, 25 Dec 1999, Bruce Momjian wrote:
>
> > >
> > >
> > > On Sat, 25 Dec 1999, Bruce Momjian wrote:
> > > > My big question is, what new challenges will we face as
> > > > we become more popular?
> > >
> > > Plug-in Oracle 7 compatibility.
> >
> > I believe we are adding Oracle compatibility as possible. We are
> > working on write-ahead log, long tuples, foreign keys, and outer joins.
> > Anything else?
>
> tablespace support ( which isnt a trivial task ), groups ( pgsql has this
> sort of functionality already, but i dont think its to the extent that
> Oracle does ), some additional grants ( 'grant connect to' ), 'alter table
> <table> add constraint <constraint definition>'...
>
> tablespace support would put pgsql soooo far ahead of most other rdbmses.
Yes. A tablespace is good feature for robus SQL engine. And (IMHO):
- raw i/o device storage manager
- replication
- privilege for columns, lock
- better speed, speed ... and speed :-)
- on-the-fly backup (from any logs)
Karel
john huttley wrote: > > I believe we are adding Oracle compatibility as possible. We are > > working on write-ahead log, long tuples, foreign keys, and outer joins. > > Anything else? > > Yes, earlier in the year I was trying to migrate from Pervasive SQL to > posgtres and > came to a screaming halt when it wouldn't do a large view. Exceeded some > sort of internal buffer > or rule area. I dont recall the details, although the mail archive will have > it. This will be fixed by Jan's new compressed type and the long fields in a second table. So in about 6 months time. The one we still need is views on UNION's... Adriaan
Hi,
Yes, I think reliability needs more work. I've had quite a few problems with
system indexes getting corrupted (number of tuples incorrect and some other
bizarre problems). Very hard to pin down as I haven't been able to reproduce any
of these cases. I've got the feeling that there may be problems when you have PL
routines used to enforce consistency constraints between several tables and the
database is being hit hard.
On the whole we are very happy with postgres and it has recently moved from one
of our development systems to a production system.
I think there has been a similar development for quite a few other people and
there are an increasing number of production Postgres systems out there. Several
people have mentioned that they could make some money available for futher
development of postgres. I also noticed that the common list of complaints (large
tuples etc) have mostly moved from the to-do to the done list.
I think there needs to be a new discussion on how best to make use of additional
resources to do things that benefit postgres most. Perhaps it would be an idea to
have the developers put together a list with tasks that are boring and that
nobody wants to do, but that would be of great benefit to the system (for
somebody who doesn't know the internals it is hard to see what may be important
tasks).
I would prefer to contribute time, but we are kind-of short of people, so that
that is pretty hard to do. The next best thing then seems to be to contribute
money in a way that benefits everybody. I'm thinking along the lines of: if a
few companies could provide $500 or $1000 and this could free up some of a
developers time to work on postgres rather than to go contracting and this time
is spent on a part of postgres that is important for production use (Vadim's work
on the transaction logs for example), then this is a good thing.
Any such process should make use of an accumulation of small contributions, as it
is amazingly difficult to explain to a finance director why you want to spend
$1000 without getting anything solid in return (while they are often quite happy
to shell out twice that for an Office licence) and many companies are small
start-ups and perhaps not that flush with cash (which is probably why they are
using postgres in the first place).
And secondly it is very important for the developers to figure out how this is
going to interact with the whole process of collaborative software development.
The last thing we want is competition for funds to impact on a collaborative
development process. I think a system like this can only operate if it is based
on consensus between the main developers.
Please feel free to flame if I'm talking bollox. In the mean-time: happy new year
to everybody!
Adriaan
data warehouse related capability. e.g., table space, table split, bitmap index, using multiple indices in one query, star-schema optimization. On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > > > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > My big question is, what new challenges will we face as > > > we become more popular? > > > > Plug-in Oracle 7 compatibility. > > I believe we are adding Oracle compatibility as possible. We are > working on write-ahead log, long tuples, foreign keys, and outer joins. > Anything else? > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************ >
Just a few questions on the Future of PostgreSQL. I plan to play with PostgreSQL project in the next few months. Since I am not yet knowledgable about the internal PostgreSQL code and nor am I an database engine expert, I thought I could work on projects that are "add-on" to PostgreSQL. All the projects I mention will be Open Source using GPL or BSD. I've figuring GPL, just because I have already found a lot code written in GPL. Here are the projects I was thinking about, yet I was concerned. Administration Tools? Are the current tools acceptable? Do you want something more? I planning on creating add-in to jEdit that would be a Visual Database designer tool that works with any JDBC database, including PostgreSQL. I was also think of taking it a step farther and making it know how to talk with PostgreSQL via a native API. For those of you familar with Visual Studio or Delphi it would look like one of these Visual Tools mixed with ideas from Oracle's Designer and Microsoft's Managment Console. Is this something the group would be instrested in? Java support in the database? Just about all the current db have support for Java in the database. As an example, Oracle has a JServer option that can be added to Oracle 8i. Would something like this be of intrest to the group? Or should I look at other things? Internet Oracle, IBM and other have all kinds of different Internet technologies such as portable version of the database -- XML, HTML export and imports, CORBA/Application Server type support. OLAP Data Warehousing doesn't have to be integrated into the database. The point is that OLAP - can be applied as an add-in to the system. The key needs is a good development tool to help your users and yourself understand the information that you know have access to. 'nough said, Jeff
On Mon, 27 Dec 1999, Jeff Duska wrote: > For those of you familar with Visual Studio or Delphi it would look like one > of these Visual Tools mixed with ideas from Oracle's Designer and > Microsoft's Managment Console. Is this something the group would be > instrested in? yes!:) > Java support in the database? > Just about all the current db have support for Java in the database. As an > example, Oracle has a JServer option that can be added to Oracle 8i. Would > something like this be of intrest to the group? Or should I look at other > things? yes!:) > > Internet > Oracle, IBM and other have all kinds of different Internet technologies such > as portable version of the database -- XML, HTML export and imports, > CORBA/Application Server type support. yes!:) mazek
Hello, Being connected to Postgres can I get to know how many connections are established at the moment and their ids if there are any? Regargs, Alexei.
On Mon, 27 Dec 1999, Jeff Duska wrote: > [SNIP] > Java support in the database? > Just about all the current db have support for Java in the database. ... which isnt where it belongs. java is (barely) an applications-level language, not a systems-level language. let your app treat the data it gets from a rdbms as an object/entity, not vice versa. i think javablend from Sun does something like this ( creating objects from rdbms data ) and im positive NeXT/Apple's Enterprise Objects Framework does this. GNUstep's 'DBkit' ( or whatever its called ) does the same thing, but is based on EOF1.0. its a much, much nicer approach to the whole issue, not to mention quite a bit more flexible and portable. > [SNIP] > Internet > Oracle, IBM and other have all kinds of different Internet technologies such > as portable version of the database -- XML, HTML export and imports, > CORBA/Application Server type support. would be rather trivial to write an export app that dumps the data into html format. in fact, psql does this already. > [SNIP] --- Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org "I've learned that you cannot make someone love you. All you can do is stalk them and hope they panic and give in."
On Mon, 27 Dec 1999, Jeff Duska wrote:
> Just a few questions on the Future of PostgreSQL. I plan to play with
> PostgreSQL project in the next few months. Since I am not yet knowledgable
> about the internal PostgreSQL code and nor am I an database engine expert, I
> thought I could work on projects that are "add-on" to PostgreSQL. All the
> projects I mention will be Open Source using GPL or BSD. I've figuring GPL,
> just because I have already found a lot code written in GPL. Here are the
> projects I was thinking about, yet I was concerned.
>
> Administration Tools? Are the current tools acceptable? Do you want
> something more?
> I planning on creating add-in to jEdit that would be a Visual Database
> designer tool that works with any JDBC database, including PostgreSQL. I was
> also think of taking it a step farther and making it know how to talk with
> PostgreSQL via a native API.
What's wrong with the existing JDBC driver? It's as close to a native api
as you can get (its internals are based on libpq).
> For those of you familar with Visual Studio or Delphi it would look like one
> of these Visual Tools mixed with ideas from Oracle's Designer and
> Microsoft's Managment Console. Is this something the group would be
> instrested in?
We already have pgaccess, but a Java based variant would IMHO be a useful
addition. You should have compatibility with pgaccess (which I believe has
forms? I've not used it, so I'm not certain on this).
I have thought about this myself, but just never had the time.
> Java support in the database?
> Just about all the current db have support for Java in the database. As an
> example, Oracle has a JServer option that can be added to Oracle 8i. Would
> something like this be of intrest to the group? Or should I look at other
> things?
We did have some discussion (ok brief) a few months ago about what it
would take to implement a "PL/Java" interface for the backend. It's not
going to be an easy thing to do, but it may have some benefits. I do have
some ideas here on that subject.
> Internet
> Oracle, IBM and other have all kinds of different Internet technologies such
> as portable version of the database -- XML, HTML export and imports,
> CORBA/Application Server type support.
I'm messing around with XML & Java at the moment for TASS, and it's not
that difficult. HTML can be done as XML (The XML DTD exists for HTML).
Corba has been a common thread recently, but is hindered by which ORB to
use, and that orbs licence and porability.
On the other hand, in the source there's a simple example of using JDBC to
link simple CORBA apps to the backend.
Peter
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
On Tue, 28 Dec 1999, Howie wrote:
> On Mon, 27 Dec 1999, Jeff Duska wrote:
>
> > [SNIP]
> > Java support in the database?
> > Just about all the current db have support for Java in the database.
>
> ... which isnt where it belongs. java is (barely) an applications-level
> language, not a systems-level language.
It's getting better and faster, but I'm not going to start that debate :-)
Lets just say that there are some sites out there that use server side
Java, and it's running virtually at the same speed as native code...
> let your app treat the data it gets from a rdbms as an object/entity,
> not vice versa. i think javablend from Sun does something like this (
> creating objects from rdbms data ) and im positive NeXT/Apple's
> Enterprise Objects Framework does this. GNUstep's 'DBkit' ( or
> whatever its called ) does the same thing, but is based on EOF1.0.
> its a much, much nicer approach to the whole issue, not to mention
> quite a bit more flexible and portable.
There are many different techniques available. In our own driver we have a
simple Class Serialization model that maps Java Classes onto PostgreSQL
tables. It's simple, but it works.
However, I think Jeff was thinking of a PL/Java scheme, where you can
write a Java class that was callable from an SQL statement. Not everyone
would want this, but if they do, it would be an option they could compile
in.
The scheme I had in mind was to have a single JVM started by the
postmaster using JNI, and when a backend is started and first requests use
of a Java method, it starts a thread in this JVM and that thread then
remains for the lifetime of the backend servicing requests.
> > [SNIP]
> > Internet
> > Oracle, IBM and other have all kinds of different Internet technologies such
> > as portable version of the database -- XML, HTML export and imports,
> > CORBA/Application Server type support.
>
> would be rather trivial to write an export app that dumps the data into
> html format. in fact, psql does this already.
I'd prefer XML, as its more general, and you could represent HTML as a
subset.
It would be a doddle to write a tool to build an XML DTD based on a
postgresql database.
Peter
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
Sorry for such trivia,
I have created a table containing an array, and I want to fill up the value...
create table test ( pl float8[][]); /* works */
insert into test values ('(1,2,3),(3,4,5)'); /* does not work */
does not work.... The answer in psql is array_in need to specify dimension..
help...
franck@sopac.org.fj
On Mon, 27 Dec 1999, Karel Zak - Zakkr wrote:
> - raw i/o device storage manager
I can't see this ever happening, since it would require having to write
low-level device drivers, vs using what the OS already has ...
One thing someone *did* mention though was that Linux(?) now has (or is
working on?) low level functions to do this...I'm not sure what would be
involved to use this functionatilty though...anyone in the Linux camp able
to respond?
Basically, if "low_level_read()" was found by configure, add in the
functionality? Something like that?
Just curious though...how do you monitor something like that? Say I do
this on a 4gig file system, and it fills up? Then what?
From what I've read in Oracle manuals, the benefits of doing raw-I/O don't
outweigh the headaches of implementing it, but if it is something that
someone wants and can implement cleanly at an *operating system* level
(similar to the Linux function calls someone previously mentioned), then
there appears to be little disadvantages ...
... but if we have to create and maintain our own device drivers, then the
headaches (long term) are definitely not worth it, since if the person
that did the driver decides to bog off, we're left with code that isn't
supported, and in an Open Source project, that means code that will
generally die and get removed :(
> - replication
This is something that alot of ppl want/are interested in...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
hi... > One thing someone *did* mention though was that Linux(?) now has (or is > working on?) low level functions to do this...I'm not sure what would be > involved to use this functionatilty though...anyone in the Linux camp able > to respond? > the latest raw i/o patches for 2.2 and 2.3 were released in august (by Stephen C. Tweedie).. they are available at: ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io/ while these mods were designed w/Linus Torvalds and passed as OK by him, the big question still remains as to whether this will ever make it into the main kernel distribution... and that probably is not going to happen unless/until there is a change of heart in the kernel development leadership... a direct quote from Linus Torvalds: "I do not believe in raw IO - even for streaming audio it's just too common for the data to have been available in the cache, and by using raw IO you (for absolutely no good reason) just made the machine do more IO than it should have. There are very specific cases where the application knows that its dataset is larger than physical memory, but those tend to be limited to quite large problems. And they're getting larger. " so, while the patches are there and "officially sanctioned" as it were, it probably won't be a standard issue item and will remain in the form of patches you have to fetch and apply yourself... for the people who will benefit from raw io, however, this probably won't be a huge issue as their installations will probably be highly tuned and tweaked anyways.. in short: the support is there for raw io in the linux kernel, just not the standard distribution. it will probably remain for as long as there is interest (which seems to mostly come from database concerns).. -- Aaron J. Seigo
The Hermit Hacker wrote: > > On Mon, 27 Dec 1999, Karel Zak - Zakkr wrote: > > > - raw i/o device storage manager > > I can't see this ever happening, since it would require having to write > low-level device drivers, vs using what the OS already has ... > > One thing someone *did* mention though was that Linux(?) now has (or is > working on?) low level functions to do this...I'm not sure what would be > involved to use this functionatilty though...anyone in the Linux camp able > to respond? > > Basically, if "low_level_read()" was found by configure, add in the > functionality? Something like that? > I haven't used raw partitions on ORACLE, but I believe its something like: CREATE TABLESPACE ADD DATAFILE '/dev/sda1'; instead of: CREATE TABLESPACE ADD DATAFILE '/home/oracle7/dbs/moredata.dbs'; so all ORACLE is doing is maintaining its own "filesystem" on top of either block special devices or filesystem files using read(), write(), fcntl() and ioctl(). Since you have to specify before-hand how much data to allocate, ORACLE will preallocate '/home/oracle/dbs/moredata.dbs' as 100M, or whatever. In the case of a special block device, it uses the entire partition. This allows you to put your "HOT" data on, say a mirrored RAID0+1 partition, and leave the rarely accessed stuff lie around as files on the filesystem. > Just curious though...how do you monitor something like that? Say I do > this on a 4gig file system, and it fills up? Then what? You had to SELECT from a system catalogue under version 6.0 - or use monitoring tools. I think ORACLE added automatically extensible tablespaces in version 7, although I suppose RAW partitions couldn't work that way. When it filled up, you would log into SQL*DBA and do a: ALTER TABLESPACE ADD DATAFILE '/dev/sda2'; to add another partition. That's why DBA's get the big bucks....right? Mike Mascari
Hi, one of the important factors that contributed to the popularity and success of Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite interesting too and I don't want to tie myself to just one platform. More platforms will bring in more users, more testers and more hackers and thus much better Postgres (hopefully). Bruce M. says Postgres depends so much on Unix that to port it would be about as hard as port the whole Unix kernel. So here's the idea for the next major release: how about some kind of 'PostgrSQL Portable Rutime' that would isolate system dependent stuff and make PostgreSQL reasonably portable? Apache has its 'Apache Portable Runtime', so has Netscape/Mozilla and while they're clearly very different applications, I believe it's not impossible. I understand this would be a LOT of work and most Postgres developers might not be immediately attracted, but look at it this way: Postgres is currently unique among db servers with its features, robustness, performance and nice licence, but what if mSQL/MySQL finally add transactions and other features and/or free their licence? Or one of the big guys, say IBM, get enlightened/desperade enough to release source? Suddenly there would be a strong competitor to Postgres and being crossplatform would give them a great advantage. I'm web developer and with Apache and Perl (and mod_perl), I'm quite happy. Now that Mozilla M12 is quite usable I can develop on almost any platform I want... but I want Postgres and it brings me back to Unix with its beautifull UI, great multimedia support and Age of Empires running under Wine. *sigh* - Robert P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very clear at this point and few months ago there were even some rumors about plans for 'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help to Mac/BeOS/VAX/mainframe people.
> P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very > > clear at this point and few months ago there were even some rumors about plans for > 'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help > to Mac/BeOS/VAX/mainframe people. We have been very lucky to have cgywin to allow us to run on NT with very few changes. My guess is that we would basically need to re-invent cgywin on those platforms because we use most/all of the modules. I guess that is what makes it sound really hard. If Cygnus has problems doing Win95 or Mac, it would be very hard for us, no? If we were just passing around bytes or doing network stuff like Apache or Perl, we would be OK. It is the shared memory and locking stuff that would really give us trouble. Cgywin gave us that. We do have _very_ clearly modular code, so someone could easily see exactly where we do each of these things. Probably the bigest hurdle is that none of the developers have any interest in these platforms. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 30 Dec 1999, Robert wrote: > Hi, > > one of the important factors that contributed to the popularity and success of > Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and > even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite > interesting too and I don't want to tie myself to just one platform. MacOS X has a Unix core ( Mach 3.0 + FreeBSD ). a few people are looking into a port to MacOS X DP2 (Developer Preview, heavily NDA'ed), but they're not sure if the guts are 'feature frozen' yet. MacOS X CR1 (Customer Release) supposidly ships ~feb 2k. id expect that the port would be relatively painless, but i'm not 100% positive. Mach would be The Big Hurdle (no pun intended) in getting pgsql to work right on the MacOS X/OS X Server platform. David Wetzel ( www.turbocat.de ) has a working EOAdaptor for MacOS X Server, OPENSTEP/Mach, and OPENSTEP/NT. ive been using it for quite a few internal projects under MacOS X Server. works great. > [SNIP] --- Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org "I've learned that you cannot make someone love you. All you can do is stalk them and hope they panic and give in."
Hi, one of the important factors that contributed to the popularity and success of Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite interesting too and I don't want to tie myself to just one platform. More platforms will bring in more users, more testers and more hackers and thus much better Postgres (hopefully). Bruce M. says Postgres depends so much on Unix that to port it would be about as hard as port the whole Unix kernel. So here's the idea for the next major release: how about some kind of 'PostgrSQL Portable Rutime' that would isolate system dependent stuff and make PostgreSQL reasonably portable? Apache has its 'Apache Portable Runtime', so has Netscape/Mozilla and while they're clearly very different applications, I believe it's not impossible. I understand this would be a LOT of work and most Postgres developers might not be immediately attracted, but look at it this way: Postgres is currently unique among db servers with its features, robustness, performance and nice licence, but what if mSQL/MySQL finally add transactions and other features and/or free their licence? Or one of the big guys, say IBM, get enlightened/desperade enough to release source? Suddenly there would be a strong competitor to Postgres and being crossplatform would give them a great advantage. I'm web developer and with Apache and Perl (and mod_perl), I'm quite happy. Now that Mozilla M12 is quite usable I can develop on almost any platform I want... but I want Postgres and it brings me back to Unix with its beautifull UI, great multimedia support and Age of Empires running under Wine. *sigh* - Robert P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very clear at this point and few months ago there were even some rumors about plans for 'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help to Mac/BeOS/VAX/mainframe people.
Robert wrote: > Hi, > one of the important factors that contributed to the popularity and success of > Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and > even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite > interesting too and I don't want to tie myself to just one platform. I share your aspirations, and your pain. :-) Some of the issues that make each platform good are the same issues that make them potentially poor candidates for certain kinds of software, until that platform matures in that area... Some things, like perl, lose some of their features on MacOS, or NT, because the features aren't available from the platform. Where this leads my thinking is to look at what each platform would not support, and then use that to determine whether the resulting product would be worth using... how much of postgres wouldn't be able to survive on other platforms? If the answer is "the binaries have compile against new libraries, which don't exist yet", that's a time consuming issue, and requires pressure on the library authors. If the issue is "memory mapping in Win2k would break all of the relational schema", that's a bit bigger. :-) > Now that > Mozilla M12 is quite usable I can develop on almost any platform I want... but I > want Postgres and it brings me back to Unix with its beautifull UI, great multimedia > support and Age of Empires running under Wine. *sigh* You've been away too long, grasshopper. KDE, Gnome, sound/video support, it's all there... I suggest you talk to the Age of Empires folks about _their_ x-plat support if you're unhappy with *nix running it under emulation. :-) -Bop -- Brought to you from iBoptheMac, a Linux/PPC iMac, currently running MacOS. Your bopping may vary.
> Bruce Momjian wrote:
>
> > My big question is, what new challenges will we face as we become more
> > popular?
>
> The 3 greatest technical/engineering challenges:
1) system reliability
> & recoverability,
2) system reliability & recoverability, and
3) system reliability
> and recoverability.
Well said ! Some other points I would like to see:
- do not go the way to add features and features and all these
features perhaps only fullfill 90% of the specifications.
- stable sql-standard execution and with all features sql offers
- remember all the groub by - having ...
- remove internal limits
- vacuumdb and the three points above ...
After working now three months with psql the situation has improved,
but I'm still not sure if I can put this database to our customers.
Marten
Bruce, > Interbase users are considering moving en-mass to PostgreSQL Inprise have just announced that they are making Interbase 6 available as open source. But no information yet on License or on how they are going to support it. I am not confident they can recruit enough volunteers and am confident that it will take a loong while to become an efficient Open Source team that is confidently developing the code. > Publishers are crawling all over each other to publish a PostgreSQL book This would be a really good thing. > My big question is, what new challenges will we face as we become more > popular? I think the overriding emphasis has been clearly stressed as stability and reliability way ahead of anything else. After that features which can help stability, reliability and speed (eg transaction logs). After that I am not so worried about much apart from support for Win9x (as I have mentioned just once or twice). > Do we have the proper license? I know this has the possibility of > opening up a GPL vs. BSD slugfest. However, I will not let such a > discussion get out of control. I am happy with the license. Regards Dave
On Tue, 4 Jan 2000, David Warnock wrote:
> > Publishers are crawling all over each other to publish a PostgreSQL
> > book
>
> This would be a really good thing.
Two books "in the works" right now...Bruce's is currently
available online off of http://www.postgresql.org ...
On Tue, 4 Jan 2000, The Hermit Hacker wrote: > On Tue, 4 Jan 2000, David Warnock wrote: > > > > Publishers are crawling all over each other to publish a PostgreSQL > > > book > > > > This would be a really good thing. > > Two books "in the works" right now...Bruce's is currently > available online off of http://www.postgresql.org ... Marc - what is number 2? ------- North Richmond Community Mental Health Center ------- Thomas Good MIS Coordinator Vital Signs: tomg@ { admin | q8 } .nrnet.org Phone: 718-354-5528 Fax: 718-354-5056 /* Member: Computer Professionals For Social Responsibility */
On Tue, 4 Jan 2000, Thomas Good wrote: > On Tue, 4 Jan 2000, The Hermit Hacker wrote: > > > On Tue, 4 Jan 2000, David Warnock wrote: > > > > > > Publishers are crawling all over each other to publish a PostgreSQL > > > > book > > > > > > This would be a really good thing. > > > > Two books "in the works" right now...Bruce's is currently > > available online off of http://www.postgresql.org ... > > Marc - what is number 2? As yet to be announced...its proposed as being more indepth, building from an "Application programming" standpoint, if memory serves ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Bruce, > > > Interbase users are considering moving en-mass to PostgreSQL > > Inprise have just announced that they are making Interbase 6 available > as open source. But no information yet on License or on how they are > going to support it. I am not confident they can recruit enough > volunteers and am confident that it will take a loong while to become an > efficient Open Source team that is confidently developing the code. > > > Publishers are crawling all over each other to publish a PostgreSQL book > > This would be a really good thing. > > > My big question is, what new challenges will we face as we become more > > popular? > > I think the overriding emphasis has been clearly stressed as stability > and reliability way ahead of anything else. > > After that features which can help stability, reliability and speed (eg > transaction logs). > > After that I am not so worried about much apart from support for Win9x > (as I have mentioned just once or twice). > Seems this is the general consensus, and this has been our order of priorities from day 1, so it looks like we are OK and heading on the right course. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Building Database Applications on the Web Using PHP3, by Hilton and Willis (Addison-Wesley, 2000), while about PHP, nevertheless covers much information on PostgreSQL. Regards, Duncan C. Kinder dckinder@mountain.net ----- Original Message ----- From: The Hermit Hacker <scrappy@hub.org> To: David Warnock <david@sundayta.co.uk> Cc: Bruce Momjian <pgman@candle.pha.pa.us>; PostgreSQL-general <pgsql-general@postgreSQL.org> Sent: Tuesday, January 04, 2000 5:20 AM Subject: Re: [GENERAL] Future of PostgreSQL > On Tue, 4 Jan 2000, David Warnock wrote: > > > > Publishers are crawling all over each other to publish a PostgreSQL > > > book > > > > This would be a really good thing. > > Two books "in the works" right now...Bruce's is currently > available online off of http://www.postgresql.org ... > > > > ************ > >
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Building Database Applications on the Web Using PHP3, by Hilton and Willis > (Addison-Wesley, 2000), while about PHP, nevertheless covers much > information on PostgreSQL. Yes, I just sent out a mention of the book. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I have added this to the PostgreSQL TODO list. > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > > My big question is, what new challenges will we face as > > > > we become more popular? > > > > > > Plug-in Oracle 7 compatibility. > > > > I believe we are adding Oracle compatibility as possible. We are > > working on write-ahead log, long tuples, foreign keys, and outer joins. > > Anything else? > > How about an SQL*Net listener... this would make > PostgreSQL plug-n-play. > > It could even be a proprietary product, thus allowing > VC's to fund it. It's a bit hard to justify changing > ODBC settings on 30+ apps on a few (hundred) thousand PC > workstations; some with hardcoded ODBC "ORA7.DLL" settings... > > Why? Oracle is going to be shutting down Oracle 7 support > soon, forcing the upgrade to Oracle 8. This will leave > hundreds (thousands accross the industry?) of applications > stranded, and not alot of money to re-write/re-deploy/re-test > them. Just a thought... at every big company I've been with, > this has been a sore spot. It could also potentially > be a good consulting revenue stream for Marc's group. > > Best, > > Clark > > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026