Re: [HACKERS] COPY TABLE TO

2003-12-22 Thread Jeroen T. Vermeulen
On Mon, Dec 22, 2003 at 10:35:08AM -, Paul Punett wrote: I need to write a tab separated text file such that the first row contains number of records in the table. Whether COPY does what you want may depend on what you want to do with special characters. If your table contains strings

[HACKERS] Reverse scans?

2004-01-16 Thread Jeroen T. Vermeulen
Would it be doable, and would it be useful, to try to alternate the directions of table and index scans every time each table/index was fully scanned? I was thinking that it could help cache performance at various levels in cases where data at the end of a large table, say, that remained in

Re: [HACKERS] Stupid question on Read Committed Isolation Level

2004-01-29 Thread Jeroen T. Vermeulen
On Thu, Jan 29, 2004 at 01:33:48PM -0400, Marc G. Fournier wrote: What happens if I abort on the first transaction? If I'm reading this Doesn't matter, because your second transaction doesn't read any of the changes you're making there--until (and if) that first one commits. The second

Re: [HACKERS] Stupid question on Read Committed Isolation Level

2004-01-29 Thread Jeroen T. Vermeulen
On Thu, Jan 29, 2004 at 06:54:21PM +0100, Jeroen T. Vermeulen wrote: On Thu, Jan 29, 2004 at 01:33:48PM -0400, Marc G. Fournier wrote: What happens if I abort on the first transaction? If I'm reading this AFAICS the part about not having inconsistencies refers only to the spectre

Re: [HACKERS] Stupid question on Read Committed Isolation Level

2004-01-29 Thread Jeroen T. Vermeulen
On Thu, Jan 29, 2004 at 02:07:25PM -0400, Marc G. Fournier wrote: If two such transactions concurrently try to change the balance of account 12345, we clearly want the second transaction to start from the updated version of the account's row To me, I read this as the first transaction has

Re: [HACKERS] Stupid question on Read Committed Isolation Level

2004-01-30 Thread Jeroen T. Vermeulen
On Thu, Jan 29, 2004 at 03:27:06PM -0400, Marc G. Fournier wrote: I would say that two such transactions concurrently heavily implies such, no? :) Like I said, the text tries to explain it--but it remains murky! ---(end of broadcast)--- TIP 3:

Re: [HACKERS] Two-phase commit

2004-02-09 Thread Jeroen T. Vermeulen
On Mon, Feb 09, 2004 at 10:09:34PM +0200, Heikki Linnakangas wrote: However, if this gets into 7.5, I guess you could just check for the version of the backend instead with SELECT version(). Hey, that works? That's very good news, because I was getting a bit worried about all the things I

Re: [HACKERS] Transaction aborts on syntax error.

2004-02-12 Thread Jeroen T. Vermeulen
On Thu, Feb 12, 2004 at 09:55:36AM +0100, Zeugswetter Andreas SB SD wrote: Yeah, but in other db's this is solved by the frontend. e.g. in Informix dbaccess has a mode that simply stops execution upon first error. So I don't think this is a nogo argument, if we added such a feature to psql.

Re: [pgsql-www] [HACKERS] Collaboration Tool Proposal

2004-02-26 Thread Jeroen T. Vermeulen
On Thu, Feb 26, 2004 at 10:49:46AM -0800, Josh Berkus wrote: Not sure. Depends on what the leads of the associated projects think. Obviously, if everyone's dead set against it, we won't do it. I for one am willing to try this in the near term. I've got an external domain (pqxx.tk)

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-26 Thread Jeroen T. Vermeulen
On Thu, Feb 26, 2004 at 09:16:38PM +0100, Peter Eisentraut wrote: In terms of improving the hosting infrastructure, this would surely be a step forward, but the problem with collaboration is not that the tools are missing, it's that people are unwilling to use any tools for issue

Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

2004-03-11 Thread Jeroen T. Vermeulen
On Thu, Mar 11, 2004 at 03:14:10PM -0800, Josh Berkus wrote: So far, only 4 people, total, have expressed opinons on the matter. I'm throwing this on Hackers so that members of projects we will be hosting can indicate whether they: A) Favor www.postgresql.net B) Favor www.pgfoundry.org

Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

2004-03-11 Thread Jeroen T. Vermeulen
On Thu, Mar 11, 2004 at 07:01:47PM -0500, Tom Lane wrote: Actually, proposal (A) does provide such a separation: notice that the projects would go under *.postgresql.net, with the core database remaining at *.postgresql.org. I am not sure if that will provoke confusion or not, but I think I

Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

2004-03-12 Thread Jeroen T. Vermeulen
On Fri, Mar 12, 2004 at 02:42:47PM -, Dave Page wrote: We need some distinction between the core project sites and other project sites - istm that a different domain is the only way to do that. Okay, then how about postgres-extra.net, or forpostgres.net? Saying Postgres instead of

Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

2004-03-12 Thread Jeroen T. Vermeulen
On Fri, Mar 12, 2004 at 10:37:58AM -0500, Tom Lane wrote: Well, if you want to think along those lines, I believe that we (PGDG) currently hold these domain names: [...] postgres.org This is the one I was silently rooting for, but figured was too good to be true. You could make a

Re: [pgsql-www] [HACKERS] The Name Game: postgresql.net vs.

2004-03-12 Thread Jeroen T. Vermeulen
On Fri, Mar 12, 2004 at 10:43:34AM -0600, Thomas Swan wrote: foundry.postgresql.org? Been through that one... Too long when you have to add project name as well. Jeroen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [pgsql-www] [HACKERS] The Name Game: postgresql.net vs.

2004-03-12 Thread Jeroen T. Vermeulen
On Fri, Mar 12, 2004 at 01:02:00PM -0600, Frank Wiles wrote: As for the length of the URL, I think any developer or user of PostgreSQL is knowledgeable enough to take advantage of browser bookmarks. :) I've heard this said a several times now, but that doesn't make me feel any

Re: [HACKERS] 7.5 beta version

2004-04-11 Thread Jeroen T. Vermeulen
On Mon, Apr 05, 2004 at 09:38:13PM -0400, Bruce Momjian wrote: I don't think you can mix libs/binaries from different compilers. As long as it's plain old C, and the compilers adhere to the platform's ABI standards, why not? Even if you compile the C code using a C++ compiler, as in this

Re: [HACKERS] 7.5 beta version

2004-04-12 Thread Jeroen T. Vermeulen
On Sun, Apr 11, 2004 at 10:21:30PM -0400, Bruce Momjian wrote: I was not sure if Win32 had standard alignment for C. Good point. There's standards, and then there's Windows. It's possible that separate tight-packing and regular pragmas are used there, just for structs that are expected to be

Re: [HACKERS] 7.5 beta version

2004-04-12 Thread Jeroen T. Vermeulen
On Mon, Apr 12, 2004 at 11:55:45AM -0700, Dann Corbit wrote: 1. The C language does not define alignment of structs. Platform ABI standards do, though (hence the as long as it adheres to... clause in my previous post). Whether it's in the C language or in the platform's ABI standards is

Re: [HACKERS] 7.5 beta version

2004-04-12 Thread Jeroen T. Vermeulen
On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote: I do know of important differences in compilers in this regard. You can (for instance) have 80 bit floating point on one compiler using double but it is only 64 bits on another. But in the case of x86 (among others) that's the

Re: [HACKERS] 7.5 beta version

2004-04-14 Thread Jeroen T. Vermeulen
On Wed, Apr 14, 2004 at 12:22:18AM +0200, Kurt Roeckx wrote: But in the case of x86 (among others) that's the in-register representation, no? IIRC they are stored to memory as 64-bit doubles at best. You also have long doubles on some compilers which could be 80 bit. Actually, they're

Re: [HACKERS] New COPY commands in libpq

2004-04-30 Thread Jeroen T. Vermeulen
On Fri, Apr 30, 2004 at 06:12:35AM -0700, Tony Reina wrote: CString cmd, msg; cmd.Format(1\t\2\t{3,4,5}\n); * PQputCopyData(conn, cmd, sizeof(cmd)); cmd.Format(\\.\n); * PQputCopyData(conn, cmd, sizeof(cmd)); * PQputCopyEnd(conn, msg); Old C++

Re: [HACKERS] New COPY commands in libpq

2004-05-01 Thread Jeroen T. Vermeulen
On Sat, May 01, 2004 at 02:25:01AM -0700, Tony Reina wrote: You might try porting your code to libpqxx, which is C++-native and should make large swathes of this sort of code unnecessary. I've seriously considered it (along with the npgsql library), but am not really sure as to what the

[HACKERS] 7.3: Change in cursor behaviour?

2002-12-02 Thread Jeroen T. Vermeulen
I've been getting reports of one of my test scenarios for libpqxx failing with postgres 7.3. At the moment I can't reproduce this (I'm still on 7.2) and I can't find anything pertinent in CVS commit messages, mailing lists etc. so I'd really appreciate any lucidity from this list. My problem

Re: [HACKERS] 7.3: Change in cursor behaviour?

2002-12-02 Thread Jeroen T. Vermeulen
On Mon, Dec 02, 2002 at 02:29:03PM -0500, Rod Taylor wrote: Seems to work the fine for me: Puzzling... Would you mind, if you have time, downloading libpqxx from GBorg and doing a ./configure; make; make check and telling me if tests 19 38 succeed? I expect them to have identical results,

Re: [HACKERS] 7.3: Change in cursor behavior?

2002-12-04 Thread Jeroen T. Vermeulen
On Wed, Dec 04, 2002 at 12:22:41AM +, Sigurdur Gunnlaugsson wrote: test=# move -10 in test_c; MOVE 4 test=# fetch 1 from test_c; schemaname | tablename | tableowner | hasindexes | hasrules | hastriggers +---+++--+- (0

[HACKERS] PQnotifies() in 7.3 broken?

2002-12-04 Thread Jeroen T. Vermeulen
Thanks to Rod Taylor's kind help in donating a system account, I've been able to test libpqxx against postgres 7.3. Unfortunately, I'm running into several problems. One thing that broke libpqxx was a change in cursor behaviour that according to Sigurdur Gunnlaugsson seems to be gone in the 7.4

Re: [HACKERS] more compile warnings

2002-12-06 Thread Jeroen T. Vermeulen
On Fri, Dec 06, 2002 at 11:16:30PM -0500, Bruce Momjian wrote: I use: -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align Some other useful ones are -pedantic -W -Wfloat-equal -Wshadow -Wcast-qual -Wwrite-strings -Wconversion -Wsign-compare -Wsign-promo. You

[HACKERS] More on cursors in 7.3

2002-12-08 Thread Jeroen T. Vermeulen
Looking at my problem with changed cursor behaviour in 7.3 again, I noticed something interesting: a cursor in 7.3 apparently does not let you scroll back to its first row at all! Neither a move backward all or a move -n where n is equal to or greater than the cursor's current position, will

Re: [HACKERS] More on cursors in 7.3

2002-12-08 Thread Jeroen T. Vermeulen
On Sun, Dec 08, 2002 at 04:28:38PM -0500, Tom Lane wrote: I believe it is true though that backing up a cursor only works for certain plan types (seqscan, indexscan, sort, maybe a couple others). That has always been true --- 7.3 is no better nor worse than prior releases. Ah, I didn't know

Re: [HACKERS] More on cursors in 7.3

2002-12-08 Thread Jeroen T. Vermeulen
On Sun, Dec 08, 2002 at 05:09:09PM -0500, Tom Lane wrote: Is any of this described in the docs somewhere? Fraid not. Damn blast. I was rather counting on cursors that could back up for my nifty CachedResult class (which acts more or less like a normal result set but transparently

Re: [HACKERS] More on cursors in 7.3

2002-12-08 Thread Jeroen T. Vermeulen
On Sun, Dec 08, 2002 at 05:28:22PM -0500, Tom Lane wrote: Well, you could dig through backend/executor/node*.c and see which of the node types pay attention to es_direction. To a first approximation it looks like these do: I'll be honest with you: I don't know much about the internals and

Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-13 Thread Jeroen T. Vermeulen
On Fri, Dec 13, 2002 at 12:34:58AM -0500, Bruce Momjian wrote: I did only minor, which I knew was safe. Do folks realize this will require recompile of applications by 7.3 users moving to 7.3.1? That seems very drastic, and there have been very few problem reports about the NOTIFY change.

Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-15 Thread Jeroen T. Vermeulen
On Sun, Dec 15, 2002 at 11:21:07AM -0500, Tom Lane wrote: However, an app linked against libpq++ would also be linked against libpq, and so the incompatibility will be flagged by the linker anyway. I can see no need to bump libpq++'s own number. Plus, of course, libpq++ being a C++ library

Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-16 Thread Jeroen T. Vermeulen
On Mon, Dec 16, 2002 at 11:01:00AM -0500, Bruce Momjian wrote: New question --- didn't we change the externally visible PGNotify structure in libpq-fe.h in 7.3, and as returned by PQnotifies: Speaking of which, what if user relies on sizeof(PGnotify::relname)? That code will recompile without

Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-16 Thread Jeroen T. Vermeulen
On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote: Speaking of which, what if user relies on sizeof(PGnotify::relname)? ^ code Jeroen ---(end of broadcast

Re: [HACKERS] EXECUTE status (was Re: [ODBC] About server side prepare)

2002-12-20 Thread Jeroen T. Vermeulen
On Fri, Dec 20, 2002 at 12:56:55PM -0500, Tom Lane wrote: No. It would break client libraries, which only expect command tags INSERT, UPDATE, DELETE to be followed by counts. And MOVE, right? Jeroen ---(end of broadcast)--- TIP 6: Have you

[HACKERS] GBorg feature requests

2002-12-25 Thread Jeroen T. Vermeulen
First off, happy holidays to all! Next, can anyone tell me the proper channel for reporting bugs and feature requests for GBorg itself? I've looked around, but I may have missed something. One feature I'd really like, is to have its automatic email notification (for bug reports, status changes

[HACKERS] MOVE strangeness

2002-12-25 Thread Jeroen T. Vermeulen
Here's something that's been bothering me for a while... Perhaps this is correct behaviour, but I can't quite see how. This does not happen if I replace the FETCHes by MOVEs. Here's the reference case: jtv= begin; BEGIN jtv= declare c cursor for select * from events; DECLARE CURSOR jtv= fetch

Re: [HACKERS] MOVE strangeness

2002-12-26 Thread Jeroen T. Vermeulen
On Thu, Dec 26, 2002 at 02:14:40PM -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Sorry, I am not understanding. If he does: ...

Re: [HACKERS] [GENERAL] Cast your vote ...

2003-01-02 Thread Jeroen T. Vermeulen
On Thu, Jan 02, 2003 at 03:07:48PM -0500, Dan Langille wrote: else to do the same. In the big picture, marketing statements like this survey mean alot more than most technical folks want to acknowledge. The figures would be a lot more interesting anyway if people bothered to correlate

Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...

2003-01-06 Thread Jeroen T. Vermeulen
On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote: AFAIK, libpq is thread-safe already, it's just not thread-aware. What you'd presumably want is a wrapper layer that adds a mutex to prevent multiple threads from manipulating a PGconn at the same time. Couldn't this be done without

Re: [HACKERS] Error using cursors/fetch and execute

2003-01-07 Thread Jeroen T. Vermeulen
On Tue, Jan 07, 2003 at 02:29:30PM +0100, Magnus Naeslund(f) wrote: mag=# create table test (id serial unique primary key, txt text); mag=# insert into test(txt) values('hoho1'); mag=# prepare berra (integer) as select * from test where id = $1; mag=# declare berra_c cursor for execute

[HACKERS] Client interfaces documentation

2003-01-24 Thread Jeroen T. Vermeulen
Something that just occurred to me: should the documentation tree still contain full documentation for the various client interfaces, now that they have been unbundled? If so, I'd very much like to see the part about libpq++ being the C++ interface changed to mention libpqxx as a replacement.

Re: [HACKERS] Contract Programmer Advice.

2003-02-11 Thread Jeroen T. Vermeulen
On Tue, Feb 11, 2003 at 08:56:56PM -0500, Lamar Owen wrote: This company doesn't dispute any of my invoices and says they are going to pay me. But they have not yet done so. This company is still in business, and I wouldn't know about your country, whichever that may be, but in the

[HACKERS] psql source suggestions

2003-02-12 Thread Jeroen T. Vermeulen
I've been playing around with the source for psql, and as a result I did some cleaning up in common.c. Would anyone be interested in seeing patches for that? The main benefit is some eliminated code duplication, plus the removal of some warts like 'continue' and 'break' where they weren't

Re: [HACKERS] regression failure - horology

2003-02-22 Thread Jeroen T. Vermeulen
On Sat, Feb 22, 2003 at 03:09:13AM -0500, Tom Lane wrote: Mph. It fails for me too when I use --enable-integer-datetimes. Looks like that patch still needs some work... Yeah. I'm really, really, *really* sorry for submitting it in the state it was in. I shouldn't have done that just

Re: [HACKERS] I cant find it or I'm just lazy ?

2003-02-25 Thread Jeroen T. Vermeulen
On Tue, Feb 25, 2003 at 02:04:50PM +0100, Christoph Haller wrote: Anyway, you may MOVE until 0 instead of FETCH, or use the COUNT() function on the query to learn about the number of rows to be returned. Hmm... Wouldn't the reliability of a count() depend on the isolation level? OTOH the

Re: [HACKERS] I cant find it or I'm just lazy ?

2003-02-25 Thread Jeroen T. Vermeulen
On Tue, Feb 25, 2003 at 05:55:59PM +, Darko Prenosil wrote: I am trying to create client buffer that will show only records that are needed by application(visible). Data should be send to client in pages, not all the data at once. The idea is not to query for data that are already

Re: [HACKERS] I cant find it or I'm just lazy ?

2003-02-25 Thread Jeroen T. Vermeulen
On Tue, Feb 25, 2003 at 07:34:12PM +, Darko Prenosil wrote: Unfortunately it is application written in QT library that should work on Windows too, but I'll take a look, I'm sure I can learn something from it ! Well, libpqxx also runs on Windows but it takes a decent compiler (e.g. Visual

Re: [HACKERS] I cant find it or I'm just lazy ?

2003-02-26 Thread Jeroen T. Vermeulen
On Wed, Feb 26, 2003 at 09:44:14AM +, Darko Prenosil wrote: I got the sources yesterday. Thank you ! Let me know whether everything works for you. There's also a mailing list on pqxx.tk if you need it. Jeroen ---(end of broadcast)--- TIP

Re: [HACKERS] talking to postgresql from C/C++

2003-03-07 Thread Jeroen T. Vermeulen
On Fri, Mar 07, 2003 at 12:14:30PM -0500, Merlin Moncure wrote: What about libpq++? I have not used the thing, but if he absolutely insists on using C++ in his database interface that's at least worth checking out. Same for embedded C. And of course there's libpqxx. I haven't heard from

Re: [HACKERS] Cursors and backwards scans and SCROLL

2003-03-10 Thread Jeroen T. Vermeulen
On Sun, Mar 09, 2003 at 03:35:11PM -0500, Tom Lane wrote: 2. Error out only if a backwards fetch is actually attempted on a plan tree that can't handle it (which could only happen if SCROLL wasn't given). This is efficient and flexible, but it exposes implementation details to the user, in

[HACKERS] Integrating libpqxx

2002-06-12 Thread Jeroen T. Vermeulen
I think libpqxx, the alternative to libpq++, is just about ready for prime time. That means integrating it with the main source tree, I suppose, but I have no idea where to start--particularly because libpqxx has its own configure setup. Anyone who can help me with this? Jeroen PS: find

Re: [HACKERS] Integrating libpqxx

2002-06-12 Thread Jeroen T. Vermeulen
On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote: Otherwise, if you put the code into src/interfaces/libpqxx and modify the PostgreSQL build system to be aware of it (as well as removing libpqxx's autoconf stuff), it shouldn't be too difficult. One concern I have on this point is

Re: [HACKERS] Integrating libpqxx

2002-06-12 Thread Jeroen T. Vermeulen
On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote: I can add it to CVS as interfaces/libpqxx and we can then let others merge your configure tests into our main configure. Let me know when you want it dumped into CVS. Might as well do it right now, with 0.5.2. We'll call that

Re: [HACKERS] Integrating libpqxx

2002-06-13 Thread Jeroen T. Vermeulen
On Wed, Jun 12, 2002 at 10:41:32PM -0400, Tom Lane wrote: I'm thinking we should just import the current state of the files and not worry about preserving their change history. Fine with me, if that's easier. I just thought it might be nice to have but I can't think of any compelling reason

Re: [HACKERS] Integrating libpqxx

2002-06-13 Thread Jeroen T. Vermeulen
On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: Jeroen ... can you send me a copy of the CVSROOT for this? Email will work ... if we can, I would like to save the development history, and I *think* I can ... I already sent one to Bruce last night, IIRC. Jeroen

[HACKERS] Case sensitive searches

2002-06-27 Thread Jeroen T. Vermeulen
I've just come across a case in Oracle 8.0.6 where important queries could have been several orders of magnitude faster if only the optimizer had realized that it was doing case-insensitive comparisons against a constant that wasn't affected by case (a string of all digits). The query was of the

Re: [HACKERS] Integrating libpqxx

2002-07-03 Thread Jeroen T. Vermeulen
On Tue, Jul 02, 2002 at 02:05:57PM -0400, Bruce Momjian wrote: Jeroen, do you have PostgreSQL CVS access yet? If not, we need to get you that. Don't have it yet, so please do! Jeroen ---(end of broadcast)--- TIP 2: you can get off all

Re: Trim the Fat (Was: Re: [HACKERS] Open 7.3 items )

2002-08-02 Thread Jeroen T. Vermeulen
On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote: Of course my humble but thoroughly biased opinion is that libpq++ be marked legacy. No doubt, but, if we didn't push one interface over another, then it would be up to the end-users themselves to decide which one to

Re: [HACKERS] AnonCVS woes

2002-08-10 Thread Jeroen T. Vermeulen
On Sat, Aug 10, 2002 at 06:05:27PM -0400, Rod Taylor wrote: P src/interfaces/libpqxx/configure.ac cvs server: Updating src/interfaces/libpqxx/config U src/interfaces/libpqxx/config/.cvsignore cvs server: Updating src/interfaces/libpqxx/debian cvs server: failed to create lock directory for

Re: [HACKERS] libpqxx

2002-08-12 Thread Jeroen T. Vermeulen
On Mon, Aug 12, 2002 at 04:44:12PM -0300, Marc G. Fournier wrote: For this, all I've been waiting for is for J to get the standalone to build and then going to dive into that ... I added Ray's changes a few days back, which may help. My handicap is that I appear to be on a newer version of

Re: [HACKERS] anoncvs currently broken

2002-08-13 Thread Jeroen T. Vermeulen
On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote: should be fixed ... looks like just an ownership issue on a new directory More like I uploaded that directory just as you were rsync'ing to anonymous CVS and a lock file got copied along, but was never deleted on a subsequent

Re: [HACKERS] Open 7.3 items

2002-08-19 Thread Jeroen T. Vermeulen
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote: integrate or move to gborg libpqxx, Pg:DBD It's no longer my CVS home tree... Is there something I can/should do for this? Jeroen ---(end of broadcast)--- TIP 1: subscribe and

[HACKERS] PREPARE and transactions

2004-06-23 Thread Jeroen T. Vermeulen
We were discussing prepared statement support for libpqxx just now (Bruce, Peter Eisentraut myself are manning the postgres booth at LinuxTag 2004 in Karlsruhe, Germany), when we ran into a problem that came up two months ago. That discussion follows: Post by Alvaro Herrera: Hackers, Is

Re: [HACKERS] PREPARE and transactions

2004-06-24 Thread Jeroen T. Vermeulen
On Wed, Jun 23, 2004 at 03:26:49PM -0400, Tom Lane wrote: Even if the spec doesn't help, I think a statement prepared within a transaction should definitely be deallocated at the end of the transaction. Uh, you do realize that Postgres does *everything* within a transaction? Well, except

Re: [HACKERS] PREPARE and transactions

2004-06-24 Thread Jeroen T. Vermeulen
On Thu, Jun 24, 2004 at 08:51:32AM -0400, Merlin Moncure wrote: When I say within a transaction as opposed to outside a transaction, I mean of course an explicit transaction. If you want a prepared statement to last throughout the session, I'd say it stands to reason that you create it

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-06-25 Thread Jeroen T. Vermeulen
On Fri, Jun 25, 2004 at 02:00:12AM -, Greg Sabino Mullane wrote: I was originally unhappy with the current situation, but now I think it is the best. Any changes will also cause a huge further headache for driver/application writers, as we already have a released version (and probably

Re: [HACKERS] PREPARE and transactions

2004-06-25 Thread Jeroen T. Vermeulen
On Thu, Jun 24, 2004 at 04:19:36PM -0400, Merlin Moncure wrote: I am using PostgreSQL as a backend for legacy COBOL applications and have written a driver which maps the COBOL I/O statements to SQL statements. To save a little bit on parsing time and for various other reasons these SQL

Re: [HACKERS] PREPARE and transactions

2004-06-25 Thread Jeroen T. Vermeulen
On Fri, Jun 25, 2004 at 10:02:29AM -0400, Tom Lane wrote: It occurs to me that a lot of the problem would go away if we allowed DEALLOCATE of a nonexistent statement to not be an error (seems like a NOTICE would be be plenty). Then you could just unconditionally DEALLOCATE anything you were

Re: [HACKERS] Default libpq service

2004-06-29 Thread Jeroen T. Vermeulen
On Tue, Jun 29, 2004 at 09:46:34PM +0200, Peter Eisentraut wrote: A while ago it was speculated that it might be nice to have a default service in libpq's pg_service.conf file that would supply missing connection parameters if none are specified elsewhere, so users could, say, set the

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-01 Thread Jeroen T. Vermeulen
Sorry for the delay, life tends to get complicated if you leave it alone for a few days... I see how making PREPARE obey rollbacks would be inconvenient for some existing code, but frankly I'm getting a bit worried about the why should I care whether what I do is committed or not? argument. I

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-01 Thread Jeroen T. Vermeulen
On Thu, Jul 01, 2004 at 04:06:06PM -0400, Merlin Moncure wrote: The big picture here is that with the current behavior, it is possible to keep track of existence of prepared statements without wrapping or even being aware of transaction activity. This is tremendously useful for handling

Re: [HACKERS] Survey: Motivation of Free/Open Source Software (F/OSS) Developers

2004-07-01 Thread Jeroen T. Vermeulen
On Mon, Jun 28, 2004 at 10:50:53PM +0200, Marc R?ttig wrote: Survey: Motivation of Free/Open Source Software (F/OSS) Developers Some remarks: - Although the MIME header doesn't say it, the document is encoded in a Windows-specific encoding. This is screwing up the apostrophes (')! - Q3

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Fri, Jul 02, 2004 at 12:30:07PM +1200, Oliver Jowett wrote: If it's that important, come up with a generic session-not-transaction syntax to temporarily escape bracketing. Do you have a proposal for this? It seems to me that if your argument is that if you want the old behaviour, you

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Fri, Jul 02, 2004 at 08:51:05AM -0400, Merlin Moncure wrote: Right now, I'm transitioning to ExexPrepared to skip the string escaping step on the client side. I would hate to lose that ability. ExecParams is a little more work to set up (doable, though). OTOH, if you're taking client

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Fri, Jul 02, 2004 at 11:18:44AM -0400, Merlin Moncure wrote: Yes, it would. It would actually make my life a lot easier (notwithstanding my minor gripe with ExecParams) because I would no longer have to deal with all the complexities surrounding prepared statements. This is A Good

Re: [HACKERS] Nested Transactions, Abort All

2004-07-02 Thread Jeroen T. Vermeulen
On Fri, Jul 02, 2004 at 05:30:49PM -0400, Alvaro Herrera wrote: You can't have subtransactions inside an implicit transaction block, so Haven't been following this thread closely, but just my 2 cents... If you collate queries using the semicolon, AFAIK the whole thing is executed as a single

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Fri, Jul 02, 2004 at 09:51:38PM -, Greg Sabino Mullane wrote: Specifically, your proposal (if I read it correctly) would require me to send in the full SQL statement every time, thus negating a major Well, like I said, it wouldn't actually _require_ this; it would just allow

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote: So many things are true. But _not_ doing so also breaks compatibility, so like I said, there are counterexamples. This is nonsense. Not changing the current behaviour cannot break compatibility, almost by definition. Almost.

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-02 Thread Jeroen T. Vermeulen
On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote: I stand by my original statement: making no change does not break compatibility. Please provide an example of PREPARE/EXECUTE use that works under 7.3/7.4 but does not work with current 7.5. Whether the transaction from 7.3/7.4

Re: [HACKERS] PREPARE and transactions

2004-07-03 Thread Jeroen T. Vermeulen
On Sat, Jul 03, 2004 at 08:20:17AM +0530, Abhijit Menon-Sen wrote: But for what it's worth, I strongly dislike the later proposal of making prepared statements anonymous, and pattern matching the statement text, especially if they reintroduce the need to quote query parameters. Only in cases

Re: [HACKERS] LinuxTag wrapup

2004-07-03 Thread Jeroen T. Vermeulen
On Sat, Jul 03, 2004 at 05:59:17PM +0200, Andreas Pflug wrote: classifying the questions we got those three days in the PostgreSQL booth on LinuxTag, we had three ever repeating topics, two of them non-surprising: - what's the difference to MyS*** - what about win32 native - what about

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-03 Thread Jeroen T. Vermeulen
On Sat, Jul 03, 2004 at 02:59:58PM +1200, Oliver Jowett wrote: I think you mean between 7.2 and 7.3. Ah, OK. I thought PREPARE had been added in 7.4. My apologies. Yes. I see PREPARE/EXECUTE as a SQL-statement-level, connection-local way of getting control over reuse of plans that

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-04 Thread Jeroen T. Vermeulen
On Sun, Jul 04, 2004 at 02:33:53PM +1200, Oliver Jowett wrote: Consider SET client_encoding then.. Does that really affect most middleware? In my situation for instance, what goes through the connection either way is just bytes to the middleware. Its interpretation is a client matter. So to

Re: [HACKERS] LinuxTag wrapup

2004-07-04 Thread Jeroen T. Vermeulen
On Sun, Jul 04, 2004 at 12:10:52AM -0400, Alvaro Herrera wrote: You made me remember that some time ago a non-tech fellow presented me as giving a talk about Postgresol ... the audience had quite a laugh. It seems nobody thought about instructing him on how to pronounce the thing ... it was

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-04 Thread Jeroen T. Vermeulen
On Sun, Jul 04, 2004 at 06:39:46PM -, Greg Sabino Mullane wrote: There's no actual extra parsing involved, as far as I can see, just pattern matching and the extraction of the variables. That sounds like parsing to me. :) Depends on your definition, I guess. I would say very

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-05 Thread Jeroen T. Vermeulen
On Mon, Jul 05, 2004 at 10:21:26AM +1200, Oliver Jowett wrote: It certainly affects the JDBC driver -- the native String representation in Java is UTF-16, so the driver transcodes between that and client_encoding for parameterized queries and query results involving strings. Oops, yeah,

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-05 Thread Jeroen T. Vermeulen
On Mon, Jul 05, 2004 at 11:44:08PM +1200, Oliver Jowett wrote: SQL session - temp tables, session variables, database contents Interchange - encoding representation Protocol - COPY, bind/execute c. Connection - socket stuff Transactions come into play at the Protocol

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-05 Thread Jeroen T. Vermeulen
On Tue, Jul 06, 2004 at 12:17:50AM +1200, Oliver Jowett wrote: 7.4/7.5's behaviour leaves the cursor state unchanged by the rollback: DECLARE foo CURSOR WITH HOLD FOR SELECT * FROM sometable BEGIN FETCH FORWARD 10 FROM foo -- returns rows 1..10 ROLLBACK BEGIN FETCH FORWARD

Re: subtransactions and FETCH behaviour (was Re: [HACKERS] PREPARE and transactions)

2004-07-05 Thread Jeroen T. Vermeulen
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote: This is a non-starter for JDBC: it has no control over when an application decides to access a ResultSet in a way that results in a FETCH of new data. From what you're telling me, I'm not sure I like JDBC! Why did they come

Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-07-12 Thread Jeroen T. Vermeulen
On Sun, Jul 11, 2004 at 07:23:13PM -0400, Bruce Momjian wrote: Were are we on deciding how PREPARE in aborted transactions should behave? Haven't gotten much further than agreeing that current behaviour is quirky. It does not follow that we agree it's bad. I would say most of us agree that

Re: [HACKERS] Binary Cursors, and the COPY command

2004-07-27 Thread Jeroen T. Vermeulen
On Mon, Jul 26, 2004 at 10:06:28PM -0400, [EMAIL PROTECTED] wrote: So what you are saying is that you should inconvenience 90% of your users to make sure they do something right? I would say that was pretty solid reasoning. Exposing 10% of users to a high data corruption risk just to get

Re: [HACKERS] try/catch macros for Postgres backend

2004-07-29 Thread Jeroen T. Vermeulen
On Thu, Jul 29, 2004 at 12:10:12AM -0400, Alvaro Herrera Munoz wrote: (The finally block, AFAIU, is executed whether an exception was raised or not, so it serves as cleanup for try and catch blocks. Somebody more knowledgeable in this OO matters may enlighten us better?) ...Or I could try.

Re: [HACKERS] try/catch macros for Postgres backend

2004-07-29 Thread Jeroen T. Vermeulen
On Thu, Jul 29, 2004 at 09:58:54AM -0400, Tom Lane wrote: Right. The last bit (FINALLY executes whether or not a CATCH block re-throws) seemed too messy to handle in my little macros, so I'm planning on leaving it out. But I'm open to the idea if anyone has a clever implementation thought.

Re: [HACKERS] COPY with column headings

2004-08-16 Thread Jeroen T. Vermeulen
On Mon, Aug 16, 2004 at 10:53:36AM -0400, Bruce Momjian wrote: Someone just asked about a COPY capability to supply the column headings as the first line of the copy statement. Do we want to support something like that? Does anyone else want such functionality? Wouldn't it be more logical,

Re: [HACKERS] COPY with column headings

2004-08-16 Thread Jeroen T. Vermeulen
On Mon, Aug 16, 2004 at 11:30:49AM -0400, Tom Lane wrote: The bigger question is whether this would do anything to satisfy the requestor. He probably wants the headings to appear in the file resulting from COPY TO file (or the psql equivalent), which this would not do. Providing the info in

Re: [HACKERS] devx article

2004-08-20 Thread Jeroen T. Vermeulen
On Sat, Aug 21, 2004 at 01:15:29AM +0200, Gaetano Mendola wrote: http://www.devx.com/dbzone/Article/20743 I notice on page 2: New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method What this does mean ? Or this one: MySQL does,

Re: [HACKERS] WIN1250 as server encoding

2004-09-15 Thread Jeroen T. Vermeulen
On Wed, Sep 15, 2004 at 05:02:44PM +0200, Peter Eisentraut wrote: Some people have requested to add WIN1250 as an allowed server encoding. So far, the order of the encoding numbers determined which ones were client-only, so in order not to renumber the encodings, I could only come up with

  1   2   >