[HACKERS] Old interfaces directory in CVS tree?
A libpqxx user just informed me that the anonymous CVS repository at anoncvs.postgresql.org still contained a 2002 version of libpqxx in the interfaces directory. I checked it out and otherwise it seems to be the current source tree--at least I found an 8.1 version number somewhere. Could someone cvs remove this old libpqxx version? Having the old code available may still be useful, but it should not be in current checkouts! Jeroen ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Differences in UTF8 between 8.0 and 8.1
Andrej Ricnik-Bay wrote: How about an ugly kludge ... split -a 3 -d -b 1048576 ../path/to/dumpfile dumpfile for i in `ls -1 dumpfile*`; do iconv -c -f UTF8 -t UTF8 $i;done cat dumpfile* new_dump Not with UTF-8... You might break in the middle of a multibyte character. Jeroen ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] transactions not working properly ?
Ali Baba wrote: can any one describe how the transaction are being handled in postgres. Pretty much the same as in any other SQL implementation, and you'd have the same problem in any database. Is this a homework assignment? Jeroen ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pgFoundry
PgFoundry has been brought up quite a bit lately. How we want it to succeed, how we want it to be the hub of PostgreSQL development. So my question is... Why isn't it? Speaking only for myself, I volunteered to have my project moved over first as a test case. This was agreed, the original plan being to start moving the project within two weeks. It stretched into months, many of them, and at some point I figured I'd asking and just wait to be notified. That must have been over a year ago by now. A lot of stuff happened to me personally over that waiting period (like living in three noncontiguous countries) so I may easily have missed, or even forgotten, an announcement on one of the mailing lists. I'm not unique, however. The same may be true of others. So if you want to encourage people to migrate to the new site, tell them about it and repeat, repeat, repeat! Post an announcement for each project that makes the jump. Bring it to the fore. Convey the fact--assuming it is one, of course--that this is where the Postgres-related projects are headed. Keep people updated. Did I mention repeat as well? Jeroen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Name change proposal
I'd like to propose that we abandon the name PostgreSQL and rename the project Postgre, to be pronounced either post-greh or post-gree. This change would have a twofold purpose: it would meet popular demand, and it would reflect my next proposal, that we abandon SQL as the query language and replace it with Tutorial D. This idea has come up before on the mailing list, but it was abandoned because most of the surveyed users pronounced Postgre-D to sound similar to Regret. The sales team felt that it might hinder market uptake. Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Finding if old transactions are running...
Bruce Momjian wrote: You can get that from pg_stat_activity, if you have the relevant stats turned on. pg_stat_activity will tell you about the oldest active query, but not about oldest open transaction. And pg_stat_activity can lose information when the network is under heavy load too. On a side note, a similar issue came up with libpqxx, in the part that deals with connections being lost while committing a transaction. The library tries to reconnect and figure out whether the commit completed or not, but it was pointed out that the commit might actually still be in progress by that time. Tom, I believe you said at the time that I should check pg_stat_activity. My current code polls it for the old backend pid. But if that is neither 100% reliable nor unconditionally available, wouldn't it be better if I just queried pg_locks for the transaction's ID? Would that work for all backend versions I can expect to see? Jeroen ---(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] Finding if old transactions are running...
[EMAIL PROTECTED] writes: pg_locks certainly seems like a better solution. Perhaps it didn't exist when you went with pg_stat_activity? Can't recall offhand. Neither do I... But I do need something that will work with at least any recent backend version--say, 7.2 or since. The more the better, really. Any idea how old pg_locks is? Note that you still want to look for your old backend's PID; it seems impractically expensive to keep track of the current transaction's XID. (At a minimum that would cost another query per xact...) Yes, I see now--I thought I had the transaction ID handy already anyway, but I didn't. Thanks. Jeroen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Trim the Fat (Was: Re: [HACKERS] Open 7.3 items )
On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote: Who cares? Those that need a C++ interface will know where to find it, and will report bugs that they have ... why should it be tested on every platform when we *might* only have those on the Linux platform using it? Well, portability's actually a lot better than that OS-wise. The thing to worry about is compilers. I've got some changes from Clinton James waiting in the wings until libpqxx's status and development home are settled. Those changes will make it compile on the latest version of Visual C++ (and I'll take some changes out again once they're no longer needed for that purpose), and most of it seems to work. What happens if/when libpqxx becomes the 'old, crufty interface' and something newer and shinier comes along? Where do we draw the line at what is in the distribution? For instance, why pgaccess vs a platform independent version of PgAdmin vs PHPPgAdmin? Hell, IMHO, PHPPgAdmin would most likely be more useful as more sites out there are running PHP then likely have TCL installed ... but someone that is using TCL/AolServer would definitely think otherwise ... Looking at it that way, it seems to me that the proper approach is to cut out all interfaces that don't talk to the backend themselves--e.g. the ones that build on top of libpq, like libpq++ and libpqxx do. Of course my humble but thoroughly biased opinion is that libpq++ be marked legacy. By branching out the fat, we make it *easier* for someone to take on development of it ... would libpqxx ever have been developed if Joergen could have just worked on libpq++ in the first place, without having to submit patches? Yes. Now STOP BRUTALIZING MY NAME! ... Phew. I feel better now. What was I saying? Ah, yes. What you say pretty much describes how libpqxx came to be: get a local copy of libpq++, try to fix it on a carte-blanche basis, find nothing salvageable, write from scratch building on libpq++'s experience. That said, I do support the idea of separately administered projects for the reasons you give. Looking at specifics first, the problem I'm stuck with for now is that I can't really work on the thing until this point is decided. Well I could, but not until the doctor lets me get back to it. Which requires, among other things, that it not give me headaches. :-) For the more general case, there's the problem of release management: who's going to be taking care of synchronizing releases? This may require some new infrastructure, such as a mailing list dedicated to the process, or one restricted to subproject maintainers. Or something. Perhaps the unbundling of subprojects justifies that version bump to 8.0 after all... Jeroen (Juliet Echo Romeo Oscar Echo November. Jeroen. No G. Note intricate order of vowels. Phonetic spelling in English would be Yeroon. Try to roll the r a little.) ---(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] Unintegrated stuff in source tree
On Wed, Jul 10, 2002 at 12:18:16AM +0200, Peter Eisentraut wrote: There seems to have been an accumulation lately of stuff that was simply dumped into the source tree without any sort of integration. I am particularly talking about interfaces/ssl and interfaces/libpqxx. No doubt both of these things are useful in the end, but as they are right now they're a headache waiting to happen. Well, I guess as the author I should comment on the libpqxx side of things here. We decided to drop it into the source tree as-is because (1) it's fairly hard to come by the autoconf/automake expertise required to make it work from the main source tree's configure script, and (2) not all systems or C++ compilers support enough of the Standard to make it work, so it ought to remain a separate, optional thing in the beginning. Libpqxx: * I'm no C++ whizz, but I guarantee that this coding style is not nearly as portable as we've tried to make libpq++ be. Who wants to answer those support calls all over again? Please explain. I'm sure this is not all portable, but what does coding style have to do with that? Sure, Microsoft compilers have a problem with it, but that's just because they don't support the basic concepts of the language. We've tried to fix that, but it's very hard to work around a bad compiler. If your compiler doesn't handle C++, don't try to compile C++ with it. I'd try to run it through more critical compilers, but according to existing compliance tests, gcc 2.95 through 3.1 happpen to be the best compilers around. As far as I know, libpqxx relies on only two things: first, the C++ standard, and second, libpq. If your system doesn't support those, why bother addressing PostgreSQL from C++ in the first place? * What's the deal with libpq++ vs. libpqxx? Who's going to want to explain that to the crowd for the next 5 years? Frankly, libpq++ was severely broken. That's a simple story to tell the crowd in 5 years' time. As it turned out, there was no way to fix it except by writing a completely new library. Use libpq++ if you must; libpqxx if you have the choice. If your compiler only supports C++ as A Better C then libpqxx is not for you. If there is some other problem with the code--and I can't say I've heard of any such case in a while--then it ought to be fixed. * Bogus Automake stuff -- hurts my eyes. ;-) Please elaborate. Like the docs say, the automake stuff was contributed by external dcvelopers, and I merely tried to edit it. If you could just say *what* is so bogus about it, perhaps it could be fixed. Just saying that it's bogus and that it hurts your eyes isn't going to help anyone. The library has its own automake setup so that it can be installed separately on systems that support it. Hopefully someone will see fit to integrate it into the existing setup at some point. This is not proprietary software, after all. * Doxygen -- is that going to be a quasi-required tool now? It comes with docs generated by doxygen. I don't think that means that doxygen is quasi-required any more than emacs is, just because some of the text may have been written with it. If reading HTML is a problem for you, you have other problems. Sure, re-generate the docs with doxygen if you like; you're going to end up with essentially the same stuff that's bundled with the library. If you think that's a useful exercise, you're better off with doxygen. If you don't, there's nothing wrong with the way things are. * Bonus points for documentation in DocBook format -- but unfortunately version 4.1, and unfortunately not integrated with the rest of the documentation set. * No build integration. These are on the to-do list, and some are beyond my control so I can't really address them. But if you have time to complain about them, perhaps you can help fix them as well. That would be most welcome; I've essentially been flying blind when writing the docs, mimicking what was already there. * Why are half the text files executable? Interesting. Haven't been able to find a single file with this problem in the libpqxx distribution archive, so they may have been mangled somewhere else. Where did you find the archive with this problem? Personally, I'm uneasy about carrying around another interface library that appears to have no basis in any sort of standard. This suggests that either you haven't actually looked at it, or you're unfamiliar with C++. The thing about libpqxx is that it makes database access adhere to standard C++ interfaces. So saying that it has no basis in any sort of standard is just plain wrong. In fact, some C++ programmers have found this tremendously useful, and some have chosen PostgreSQL over competing databases because of this library. Now if you want to maintain that it doesn't adhere to an existing, set standard for C++ database access you may have a point--because there currently are none (unless you count industry standards
Re: [HACKERS] Unintegrated stuff in source tree
On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote: Has the author been given CVS access yet? Yes, he has. I got him in touch with Marc. I was just pointing out that while he knows C++, he needs help getting the connecting stuff merged to our coding style. Haven't had a reply from Marc yet, so I guess I don't have CVS access yet. Anyway, my main problem at this time is know how to begin to integrate the automake/autoconf stuff into the main source tree. Can't say I know a whole lot about these tools or how PostgreSQL uses them, so as you say I'll need some help making this work in harmony with the PostgreSQL stuff. Any takers? Jeroen ---(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] libpq++ build problems
On Wed, Jul 03, 2002 at 02:25:46PM +0800, Christopher Kings-Lynne wrote: OK, this is what I'm seeing on FreeBSD/Alpha for libpq++. [cut] [paste] cc1plus: warning: *** *** The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM *** Doesn't say it doesn't work though... Have you tried running the resulting code? I haven't figured out how to build libpqxx yet.: Basically, ./configure; make; make check; make install. You may have to use configure options --with-postgres=/your/postgres/dir or its cousins. Plus, you'll also run into the same gcc warning so you may have to set the environment variable CXXFLAGS to something like -O before running configure. The same will probably help with libpq++ as well BTW. Jeroen ---(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] libpq++ build problems
On Wed, Jul 03, 2002 at 01:45:56PM -0400, Bruce Momjian wrote: Actually, I am confused. In src/template/freebsd I see: CFLAGS='-pipe' case $host_cpu in alpha*) CFLAGS=$CFLAGS -O;; i386*)CFLAGS=$CFLAGS -O2;; esac so why is he seeing the -O2 flag on FreeBSD/alpha? Probably because CXXFLAGS still has -O2 set. Jeroen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] database access via c++ program...
On Wed, Jun 26, 2002 at 12:22:54PM +0900, Emilio Uy III wrote:
I am just wondering, because I have installed PostgreSQL on my Cygwin
(Windows NT) and this is my first time to attempt a dive into the database
realm. I am not sure of this, but there should be a way to access a database
through say, a C++ program. Right now my Cygwin-PostgreSQL database is
working fine, I was able to create databases and tables, view them, modify
the contents, etc. But what I really want to do right now is to create a
simple program that would successfully connect to my PostgreSQL databases (i
have to specify the database i assume). Just a 5-liner maybe, just to test
the connection.
If you're using gcc or a similarly good compiler (Visual C++ will NOT work),
try libpqxx:
http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html
I don't know how well it installs under Cygwin, but a simple test program
using libpqxx as its C++ interface to PostgreSQL can be something like:
#include iostream
#include pqxx/connection.h
#include pqxx/transaction.h
#include pqxx/result.h
using namespace std;
using namespace pqxx;
int main()
{
try
{
Connection C(dbname=mydatabase);
Transaction T(C, T);
Result R = T.Exec(SELECT * FROM pg_tables);
for (Result::const_iterator c = R.begin();
c != R.end();
++c)
{
cout c[0].c_str() endl;
}
T.Commit();
}
catch (const exception e)
{
cerr e.what() endl;
return 1;
}
return 0;
}
HTH,
Jeroen
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
