[HACKERS] Big 7.4 items : table attachment
Dear all, Why not use libgda, Gnome-DB database provider, to be able to attach foreign tables inside PostgreSQL. Would it be hard to achieve? Many users are looking for such a solution to be able to query/update tables outside PostgreSQL in Oracle, MS SQL Server, IBM DB2 or even MySQL databases. Cheers, Jean-Michel POURE ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Peter Eisentraut wrote: Marc G. Fournier writes: It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. I am a long term user of PostgreSQL and I think it suffers from a lack of a marketing department. If you have the best restaurant in town, but no one eats there, what's the point? We all correspond and work on PostgreSQL to make it the best we can. To create something good that people can use. One of the prime parts of that sentence is people can use. Like it or not, that means getting the word out. MySQL is an appalling database, but people use it, a lot! Why? Because they really market it. They push it. They craft deceptive benchmarks which show it is better. PostgreSQL doesn't even need to be deceptive. My company is working on a Suite of applications and PostgreSQL is a key component. We will be doing our own local marketing, but it it would help if the PostgreSQL core understood that a clean professional looking website, geared toward end users would make a big difference. Furthermore, I think it would be very rewarding for everyone involved if we could get some of the street cred that MySQL has. PostgreSQL *is* a better database in almost every way. If MySQL virtually owns the open source mind share for SQL databases, it is our fault. Peter, Tom, Bruce, et al. you guys do a great job, IMHO PostgreSQL isn't lacking in anything technical, as of 7.2, with non-locking vacuum, I would consider it a viable database with no caveats. 7.3 is superior. A pure Win32 version would be awesome. I just think that if we could get people equally talented at spreading the word and making the noise, it would make a big difference in the number of users. More users eventually translates to more funding or development. Wouldn't you like to say to someone: I contribute the PostgreSQL project and have them say Cool instead of What's that? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Hi, On Sat, 2002-12-14 at 13:26, mlw wrote: MySQL is an appalling database, but people use it, a lot! Why? Because they really market it. They push it. They craft deceptive benchmarks which show it is better. PostgreSQL doesn't even need to be deceptive. snip Furthermore, I think it would be very rewarding for everyone involved if we could get some of the street cred that MySQL has. PostgreSQL *is* a better database in almost every way. If MySQL virtually owns the open source mind share for SQL databases, it is our fault. I do NOT like hearing about MySQL in this (these) list(s). PostgreSQL is not in the same category with MySQL. MySQL is for *dummies*, not database admins. I do not even call it a database. I have never forgotten my data loss 2,5 years ago; when I used MySQL for just 2 months!!! If we want to sell PostgreSQL, we should talk about, maybe, Oracle. I have never took care of MySQL said. I just know that I'm running PostgreSQL since 2,5 years and I only stopped it JUST before upgrades of PostgreSQL. It's just *working*; which is unfamiliar to MySQL users. I've presented about 28 seminars in last 12 months on PostgreSQL... In all of them, I always tried to avoid talking about MySQL. But always hit Oracle. I'm sick of hearing such sentences : We paid to Oracle, we hold 1 GB of data!. Even MySQL can hold that amount of data :-) Also, I have something to say about win32 port. I'm a Linux user. I'm happy that PostgreSQL does not have win32 version. If someone wants to use a real database server, then they should install Linux (or *bsd,etc). This is what Oracle offers,too. Native Windows support will cause some problems; such as some dummy windows users will begin using it. I do not believe that PostgreSQL needs native windowz support. So, hackers (I'm not a hacker) should decide whether PostgreSQL should be used widely in real database apps, or it should be used even by dummy users? I prefer the first one, if we want to compete with Oracle; not MySQL. Best regards, -- Devrim GUNDUZ TR.NET System Support Specialist [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
- Original Message - From: Devrim GÜNDÜZ [EMAIL PROTECTED] To: PostgreSQL-development [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 4:58 PM Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Also, I have something to say about win32 port. I'm a Linux user. I'm happy that PostgreSQL does not have win32 version. If someone wants to use a real database server, then they should install Linux (or *bsd,etc). This is what Oracle offers,too. Native Windows support will cause some problems; such as some dummy windows users will begin using it. I do not believe that PostgreSQL needs native windowz support. Ooops. I'm a Linux user too, but i have a SCO Openserver, UnixWare, Netware and lot of windows boxes in my office. Also I have Informix, Sybase ... etc. This isn't for my entertainment. Our customers need to use a real database server. But what about small business? A lot of our small customers can't spent money for dedicated linux box :((( I spent 2 month in trying open source databases (PostgreSQL, SAP DB, Interbase/Firebird) finaly i choose PostgreSQL. Now we port one of our products from Sybase SQL Anywhere to PostgreSQL. We have more than 100 customers with small networks (2-10). Most of them cant't aford dedicated linux box. Another situation DHL Bulgaria and TNT Worldwide Express Bulgaria are our customers too. In HQ they choose windows nt (i don't comment how smart is this decision), pay a lot of money to mr.Gates and now what - we say PostgreSQL is great , but .. ( and i have personal contacts with their sysadmins i don't believe they are dummy windows users) So if you don't want windows support just don't use it! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Hi, On Sat, 2002-12-14 at 15:31, Igor Georgiev wrote: snip In HQ they choose windows nt (i don't comment how smart is this decision), pay a lot of money to mr.Gates and now what - we say PostgreSQL is great , but .. ( and i have personal contacts with their sysadmins i don't believe they are dummy windows users) Hey, I did not say that any windowz user is dummy. If you read my previous post from the beginning; you'll see that my target is MySQL users on Windows... What I've been trying to say that is: If we have a chance to choose, I'd prefer using PostgreSQL in *nix systems. This is what I've been doing since 2,5 years. So if you don't want windows support just don't use it! I can't, even if I want it; since I do not have a windows installed computer. ;-) Anyway, this will be a windows-linux discussion; which is offtopic for this list. Best regards, -- Devrim GUNDUZ TR.NET System Support Specialist [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Big 7.4 items - Replication
This sounds like two-phase commit. While it will work, it is probably slower than Postgres-R's method. --- Al Sutton wrote: For live replication could I propose that we consider the systems A,B, and C connected to each other independantly (i.e. A has links to B and C, B has links to A and C, and C has links to A and B), and that replication is handled by the node receiving the write based transaction. If we consider a write transaction that arrives at A (called WT(A)), system A will then send WT(A) to systems B and C via it's direct connections. System A will receive back either an OK response if there are not conflicts, a NOT_OK response if there are conflicts, or no response if the system is unavailable. If system A receives a NOT_OK response from any other node it begins the process of rolling back the transaction from all nodes which previously issued an OK, and the transaction returns a failure code to the client which submitted WT(A). The other systems (B and C) would track recent transactions and there would be a specified timeout after which the transaction is considered safe and could not be rolled out. Any system not returning an OK or NOT_OK state is assumed to be down, and error messages are logged to state that the transaction could not be sent to the system due it it's unavailablility, and any monitoring system would alter the administrator that a replicant is faulty. There would also need to be code developed to ensure that a system could be brought into sync with the current state of other systems within the group in order to allow new databases to be added, and faulty databases to be re-entered to the group. This code could also be used for non-realtime replication to allow databases to be syncronised with the live master. This would give a multi-master solution whereby a write transaction to any one node would guarentee that all available replicants would also hold the data once it is completed, and would also provide the code to handle scenarios where non-realtime data replication is required. This system assumes that a majority of transactions will be sucessful (which should be the case for a well designed system). Comments? Al. - Original Message - From: Darren Johnson [EMAIL PROTECTED] To: Jan Wieck [EMAIL PROTECTED] Cc: Bruce Momjian [EMAIL PROTECTED]; [EMAIL PROTECTED]; PostgreSQL-development [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 1:28 AM Subject: [mail] Re: [HACKERS] Big 7.4 items Lets say we have systems A, B and C. Each one has some changes and sends a writeset to the group communication system (GSC). The total order dictates WS(A), WS(B), and WS(C) and the writes sets are recieved in that order at each system. Now C gets WS(A) no conflict, gets WS(B) no conflict, and receives WS(C). Now C can commit WS(C) even before the commit messages C(A) or C(B), because there is no conflict. And that is IMHO not synchronous. C does not have to wait for A and B to finish the same tasks. If now at this very moment two new transactions query system A and system C (assuming A has not yet committed WS(C) while C has), they will get different data back (thanks to non-blocking reads). I think this is pretty asynchronous. So if we hold WS(C) until we receive commit messages for WS(A) and WS(B), will that meet your synchronous expectations, or do all the systems need to commit the WS in the same order and at the same exact time. It doesn't lead to inconsistencies, because the transaction on A cannot do something that is in conflict with the changes made by WS(C), since it's WS(A)2 will come back after WS(C) arrived at A and thus WS(C) arriving at A will cause WS(A)2 to rollback (WS used synonymous to Xact in this context). Right Hope this doesn't add too much confusion :-) No, however I guess I need to adjust my slides to include your definition of synchronous replication. ;-) Darren ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Big 7.4 items - Replication
--En cette belle journée de samedi 14 décembre 2002 11:59 -0500, -- Bruce Momjian écrivait avec ses petits doigts : This sounds like two-phase commit. While it will work, it is probably slower than Postgres-R's method. What exactly is Postgres-R's method ? -- Mathieu Arnold ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Big 7.4 items - Replication
I see it as very difficult to avoid a two stage process because there will be the following two parts to any transaction; 1) All databases must agree upon the acceptability of a transaction before the client can be informed of it's success. 2) All databases must be informed as to whether or not the transaction was accepted by the entire replicant set, and thus whether it should be written to the database. If stage1 is missed then the client application may be informed of a sucessful transaction which may fail when it is replicated to other databases. If stage 2 is missed then databases may become out of sync because they have accepted transactions that were rejected by other databases. From reading the PDF on Postgres-R I can see that either one of two things will occur; a) There will be a central point of synchronization where conflicts will be tested and delt with. This is not desirable because it will leave the synchronization and replication processing load concentrated in one place which will limit scaleability as well as leaving a single point of failure. or b) The Group Communication blob will consist of a number of processes which need to talk to all of the others to interrogate them for changes which may conflict with the current write that being handled and then issue the transaction response. This is basically the two phase commit solution with phases moved into the group communication process. I can see the possibility of using solution b and having less group communication processes than databases as attempt to simplify things, but this would mean the loss of a number of databases if the machine running the group communication process for the set of databases is lost. Al. - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Al Sutton [EMAIL PROTECTED] Cc: Darren Johnson [EMAIL PROTECTED]; Jan Wieck [EMAIL PROTECTED]; [EMAIL PROTECTED]; PostgreSQL-development [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 4:59 PM Subject: [mail] Re: [HACKERS] Big 7.4 items - Replication This sounds like two-phase commit. While it will work, it is probably slower than Postgres-R's method. -- - Al Sutton wrote: For live replication could I propose that we consider the systems A,B, and C connected to each other independantly (i.e. A has links to B and C, B has links to A and C, and C has links to A and B), and that replication is handled by the node receiving the write based transaction. If we consider a write transaction that arrives at A (called WT(A)), system A will then send WT(A) to systems B and C via it's direct connections. System A will receive back either an OK response if there are not conflicts, a NOT_OK response if there are conflicts, or no response if the system is unavailable. If system A receives a NOT_OK response from any other node it begins the process of rolling back the transaction from all nodes which previously issued an OK, and the transaction returns a failure code to the client which submitted WT(A). The other systems (B and C) would track recent transactions and there would be a specified timeout after which the transaction is considered safe and could not be rolled out. Any system not returning an OK or NOT_OK state is assumed to be down, and error messages are logged to state that the transaction could not be sent to the system due it it's unavailablility, and any monitoring system would alter the administrator that a replicant is faulty. There would also need to be code developed to ensure that a system could be brought into sync with the current state of other systems within the group in order to allow new databases to be added, and faulty databases to be re-entered to the group. This code could also be used for non-realtime replication to allow databases to be syncronised with the live master. This would give a multi-master solution whereby a write transaction to any one node would guarentee that all available replicants would also hold the data once it is completed, and would also provide the code to handle scenarios where non-realtime data replication is required. This system assumes that a majority of transactions will be sucessful (which should be the case for a well designed system). Comments? Al. - Original Message - From: Darren Johnson [EMAIL PROTECTED] To: Jan Wieck [EMAIL PROTECTED] Cc: Bruce Momjian [EMAIL PROTECTED]; [EMAIL PROTECTED]; PostgreSQL-development [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 1:28 AM Subject: [mail] Re: [HACKERS] Big 7.4 items Lets say we have systems A, B and C. Each one has some changes and sends a writeset to the group communication system (GSC). The total order dictates WS(A), WS(B), and WS(C) and the writes sets are recieved in that order at each system. Now C gets WS(A)
Re: [mail] Re: [HACKERS] Big 7.4 items - Replication
b) The Group Communication blob will consist of a number of processes which need to talk to all of the others to interrogate them for changes which may conflict with the current write that being handled and then issue the transaction response. This is basically the two phase commit solution with phases moved into the group communication process. I can see the possibility of using solution b and having less group communication processes than databases as attempt to simplify things, but this would mean the loss of a number of databases if the machine running the group communication process for the set of databases is lost. The group communication system doesn't just run on one system. For postgres-r using spread there is actually a spread daemon that runs on each database server. It has nothing to do with detecting the conflicts. Its job is to deliver messages in a total order for writesets or simple order for commits, aborts, joins, etc. The detection of conflicts will be done at the database level, by a backend processes. The basic concept is if all databases get the writesets (changes) in the exact same order, apply them in a consistent order, avoid conflicts, then one copy serialization is achieved. (one copy of the database replicated across all databases in the replica) I hope that explains the group communication system's responsibility. Darren ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PQnotifies() in 7.3 broken?
OK, I have updated the libpq major number in 7.3.X, and updated major and minor in HEAD. Do I need to increment the other interfaces that _use_ libpq, like ecpg? I think so. --- Oliver Elphick wrote: On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote: OK, let me see if I understand the ramifications. If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and you your old binaries will continue to work. However, if you delete the old libraries, then install, anything compiled against 7.3 will not work until it is recompiled. Yes. You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2 from 7.3 (and also from 7.2.x, though in fact they are different). If you have installed 7.3.1 on top of 7.3, you will have libpq.so.3 (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to libpq.so.2.2) from an earlier release. Also, any new linking against a 7.3.1 that has both major version numbers will use the newer major? Is that right? 7.3.1 will only have the new major version number; the old one will have come from 7.3 or earlier. The library chosen by the linker is the one linked to libpq.so. -- Oliver Elphick [EMAIL PROTECTED] LFIX Limited -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Information schema now available
Peter Eisentraut kirjutas L, 14.12.2002 kell 05:32: A basic version of the SQL information schema is now available in newly initdb'ed database installations. Could you also post it somewhere as a plain SQL script for 7.3 ? IMHO this should become the default way for \d, ODBC, JDBC, and other similar interfaces for getting at this information and making it available for 7.3 would give the implementors of those a head start. There's still a bunch of work to do to create all the views that the spec defines. I'm sure you will get more help if it is available as add-on for 7.3. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Library Versions (was: PQnotifies() in 7.3 broken?)
OK, I have added this to tools/RELEASE_CHANGES. New file attached.
---
Lee Kindness wrote:
Guys, can I take this chance to summarise the thread and when the
major and minor versions should be updated, perhaps could be added to
the developers FAQ if everyone is in agreement?
Major Version
=
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but limited to:
1. Removing a public function or structure (or typedef, enum, ...)
2. Modifying a public functions arguments.
3. Removing a field from a public structure.
3. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.
Adding a new function would NOT force an increase in the major version
number. When the major version is increased all applications which
link to the library MUST be recompiled - this is not desirable. When
the major version is updated the minor version gets reset.
Minor Version
=
The minor version number should be updated whenever the functionality
of the library has changed, typically and change in source code
between releases would mean an increase in the minor version number so
long as it does not require a major version increase.
Thanks, Lee.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
* Version numbers
configure.in and configure
bump interface version numbers
o src/interfaces/*/Makefile
o src/interfaces/libpq/libpq.rc
o src/include/pg_config.h.win32
* Release notes
update HISTORY and later doc/src/sgml/release.sgml
* Documentation
document all new features
update help output from inside the programs
doc/src/sgml/ref manual pages
* Ports
update ports list in doc/src/sgml/installation.sgml
platform-specific FAQ's, if needed
* Miscellaneous files
doc/bug.template
* Update pg_upgrade to handle new version, or disable
* Update copyright year?
---
Major Version
=
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited to:
1. Removing a public function or structure (or typedef, enum, ...)
2. Modifying a public functions arguments.
3. Removing a field from a public structure.
3. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.
Adding a new function would NOT force an increase in the major version
number. When the major version is increased all applications which
link to the library MUST be recompiled - this is not desirable. When
the major version is updated the minor version gets reset.
Minor Version
=
The minor version number should be updated whenever the functionality
of the library has changed, typically and change in source code
between releases would mean an increase in the minor version number so
long as it does not require a major version increase.
Minimizing Changes
==
When modifying public functions arguments, steps should be taken to
maintain binary compatibility across minor PostgreSQL releases (e.g. the
7.2 series, the 7.3 series, the 7.4/8.0 series). Consider the following
function:
void print_stuff(int arg1, int arg2)
{
printf(stuff: %d %d\n, arg1, arg2);
}
If we wanted to add a third argument:
void print_stuff(int arg1, int arg2, int arg3)
{
printf(stuff: %d %d %d\n, arg1, arg2, arg3);
}
Then doing it like this:
void print_stuff2(int arg1, int arg2, int arg3)
{
printf(stuff: %d %d %d\n, arg1, arg2, arg3);
}
void print_stuff(int arg1, int arg2)
{
print_stuff(arg1, arg2, 0);
}
would maintain binary compatibility. Obviously this would add a fair
bit of cruft if used extensively, but considering the changes between
minor versions would probably be worthwhile to avoid bumping library
major version. Naturally in the next major version print_stuff() would
assume the
Re: [HACKERS] Library Versions (was: PQnotifies() in 7.3 broken?)
I have added this info too.
---
Lee Kindness wrote:
Guys,
Some further comments on bumbing the major version number which aren't
so cut-n-dry...
Lee Kindness writes:
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but limited to:
1. Removing a public function or structure (or typedef, enum, ...)
2. Modifying a public functions arguments.
3. Removing a field from a public structure.
3. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.
For #2 steps could be taken to maintain binary compatibility across
minor PostgreSQL releases (e.g. the 7.2 series, the 7.3 series, the
7.4/8.0 series). Consider the following function
void print_stuff(int arg1, int arg2)
{
printf(stuff: %d %d\n, arg1, arg2);
}
If we wanted to add a third argument:
void print_stuff(int arg1, int arg2, int arg3)
{
printf(stuff: %d %d %d\n, arg1, arg2, arg3);
}
Then doing it like this:
void print_stuff2(int arg1, int arg2, int arg3)
{
printf(stuff: %d %d %d\n, arg1, arg2, arg3);
}
void print_stuff(int arg1, int arg2)
{
print_stuff(arg1, arg2, 0);
}
would maintain binary compatibility. Obviously this would add a fair
bit of cruft if used extensively, but considering the changes between
minor versions would probably be worthwhile to avoid bumping library
major version. Naturally in the next major version print_stuff() would
assume the functionality and arguments of print_stuff2().
Lee.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] PQnotifies() in 7.3 broken?
I figured out why I forgot to update the minor number for 7.3. The old RELEASE_CHANGES file had: bump interface version numbers o src/interfaces/libpq/libpq.rc o src/include/pg_config.h.win32 I had forgotten to explicitly list the Makefile changes. The new list is: bump interface version numbers o src/interfaces/*/Makefile o src/interfaces/libpq/libpq.rc o src/include/pg_config.h.win32 Of course, incrementing the minor number may not have even helped us because we needed a major increase, which I didn't understand at the time. --- Oliver Elphick wrote: On Fri, 2002-12-13 at 19:13, Bruce Momjian wrote: OK, let me see if I understand the ramifications. If you install 7.3.1 _on_top_of 7.3, both major versions will exist, and you your old binaries will continue to work. However, if you delete the old libraries, then install, anything compiled against 7.3 will not work until it is recompiled. Yes. You will have libpq.so.3.0 in 7.3.1; and you have libpq.so.2.2 from 7.3 (and also from 7.2.x, though in fact they are different). If you have installed 7.3.1 on top of 7.3, you will have libpq.so.3 (symlinked to libpq.so.3.0) from 7.3.1, and libpq.so.2 (symlinked to libpq.so.2.2) from an earlier release. Also, any new linking against a 7.3.1 that has both major version numbers will use the newer major? Is that right? 7.3.1 will only have the new major version number; the old one will have come from 7.3 or earlier. The library chosen by the linker is the one linked to libpq.so. -- Oliver Elphick [EMAIL PROTECTED] LFIX Limited -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQnotifies() in 7.3 broken?
On Sat, 2002-12-14 at 18:59, Bruce Momjian wrote: OK, I have updated the libpq major number in 7.3.X, and updated major and minor in HEAD. Do I need to increment the other interfaces that _use_ libpq, like ecpg? I think so. I don't think so. $ ldd /usr/lib/postgresql/lib/libecpg.so libpq.so.2 = /usr/lib/libpq.so.2 (0x40019000) libc.so.6 = /lib/libc.so.6 (0x4002e000) libssl.so.0.9.6 = /usr/lib/i686/libssl.so.0.9.6 (0x40141000) libcrypto.so.0.9.6 = /usr/lib/i686/libcrypto.so.0.9.6 (0x4016e000) libkrb5.so.17 = /usr/lib/libkrb5.so.17 (0x40226000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x4025c000) libresolv.so.2 = /lib/libresolv.so.2 (0x40289000) libnsl.so.1 = /lib/libnsl.so.1 (0x4029a000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) libdl.so.2 = /lib/libdl.so.2 (0x402ad000) libcom_err.so.1 = /usr/lib/libcom_err.so.1 (0x402b) libasn1.so.5 = /usr/lib/libasn1.so.5 (0x402b2000) libroken.so.9 = /usr/lib/libroken.so.9 (0x402d2000) libdb3.so.3 = /usr/lib/libdb3.so.3 (0x402e3000) Here libecpg will look for libpq.so.2. When 7.3.1 is released, this libecpg will be replaced by one that looks for libpq.so.3. But I think that, unless the API of libecpg changes, its version should stay the same. If you change it with libpq, you must also change it with all the other libraries it links in, like libkrb5 and libdb3. That is clearly impracticable. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C But I will hope continually, and will yet praise thee more and more. Psalms 71:14 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Devrim G?ND?Z wrote: I do NOT like hearing about MySQL in this (these) list(s). PostgreSQL is not in the same category with MySQL. MySQL is for *dummies*, not database admins. I do not even call it a database. I have never forgotten my data loss 2,5 years ago; when I used MySQL for just 2 months!!! I think you're on to something here, but it's obscured by the way you said it. There's no question in my mind that PostgreSQL is superior in almost every way to MySQL. For those of us who are technically minded, it boggles the mind that people would choose MySQL over PostgreSQL. Yet they do. And it's important to understand why. Simply saying MySQL has better marketing isn't enough. It's too simple an answer and obscures some issues that should probably be addressed. People use MySQL because it's very easy to set up, relatively easy to maintain (when something doesn't go wrong, that is), is very well documented and supported, and is initially adequate for the task they have in mind (that the task may change significantly such that MySQL is no longer adequate is something only those with experience will consider). PostgreSQL has come a long way and, with the exception of a few minor things (the need to VACUUM, for instance. The current version makes the VACUUM requirement almost a non-issue as regards performance and availability, but it really should be something that the database takes care of itself), is equivalent to MySQL in the above things except for documentation and support. MySQL's documentation is very, very good. My experience with it is that it's possible, and relatively easy, to find information about almost anything you might need to know. PostgreSQL's documentation is good, but not quite as good as MySQL's. It's not quite as complete. For instance, I didn't find any documentation at all in the User's Guide or Administrator's Guide on creating tables (if I missed it, then that might illustrate that the documentation needs to be organized slightly differently). I did find a little in the tutorial (about the amount that you'd want in a tutorial), but to find out more I had to go to the SQL statement reference (in my case I was looking for the means by which one could create a constraint on a column during table creation time). The reason this is important is that the documentation is *the* way people are going to learn the database. If it's too sparse or too disorganized, people who don't have a lot of time to spend searching through the documentation for something may well decide that a different product (such as MySQL) would suit their needs better. The documentation for PostgreSQL improves all the time, largely in response to comments such as this one, and that's a very good thing. My purpose in bringing this up is to show you what PostgreSQL is up against in terms of widespread adoption. If we want to sell PostgreSQL, we should talk about, maybe, Oracle. I have never took care of MySQL said. I just know that I'm running PostgreSQL since 2,5 years and I only stopped it JUST before upgrades of PostgreSQL. It's just *working*; which is unfamiliar to MySQL users. The experience people have with MySQL varies a lot, and much of it has to do with the load people put on it. If MySQL were consistently bad and unreliable it would have a much smaller following (since it's not in a monopoly position the way Microsoft is). But you're mistaken if you believe that MySQL isn't competition for PostgreSQL. It is, because it serves the same purpose: a means of storing information in an easily retrievable way. Selling potential MySQL users on PostgreSQL should be easier than doing the same for Oracle users because potential MySQL users have at least already decided that a free database is worthy of consideration. As their needs grow beyond what MySQL offers, they'll look for a more capable database engine. It's a target market that we'd be idiots to ignore, and we do so at our peril (the more people out there using MySQL, the fewer there are using PostgreSQL). I'm a Linux user. I'm happy that PostgreSQL does not have win32 version. If someone wants to use a real database server, then they should install Linux (or *bsd,etc). This is what Oracle offers,too. Native Windows support will cause some problems; such as some dummy windows users will begin using it. I do not believe that PostgreSQL needs native windowz support. I hate to break it to you (assuming that I didn't misunderstand what you said), but Oracle offers a native Windows port of their database engine, and has done so for some time. It's *stupid* to ignore the native Windows market. There are a lot of people who need a database engine to store their data and who would benefit from a native Windows implementation of PostgreSQL, but aren't interested in the additional burden of setting up a Linux server because they lack the money, time, or expertise. So, hackers (I'm not a hacker) should decide whether
