Re: [HACKERS] Patch to update libpqxx's homepage in README

On Sun, February 10, 2008 18:35, Gurjeet Singh wrote: > libpqxx seems to have moved around quite a bit. The attached patch > corrects > libpqxx's homepage. Thanks for that. However just http://pqxx.org/ would be best. I'm just setting up new hosting, and I may not get everything completely link-

Re: [HACKERS] PAM authentication fails for local UNIX users

On Mon, August 20, 2007 19:52, Andrew Dunstan wrote: > I'd rather see an HBA fallback mechanism, which I suspect might overcome > most of the problems being encountered here. I implemented a form of that once, so on local connections you could do ident mapping with fallback to PAM or some other

Re: [HACKERS] postgresql compile problem

On Wed, July 18, 2007 11:07, [EMAIL PROTECTED] wrote: > Eecently, I have downloaded the postgresql-8.1.9.tar.gz from the official > website,and then I install in my linux System ,whose gcc version is > 2.9.6.Although I can install it successfully,then result version I check > is 7.2.1~£¬and how ca

Re: [HACKERS] ANALYZE and index/stats degradation

On Mon, July 2, 2007 22:17, Gregory Stark wrote: > The way you described it there were records being inserted and later > deleted. > Why wouldn't you need vacuums? > > Or are all the records eventually deleted and then the table truncated or > dropped before the next batch of inserts? In a nuthsh

Re: [HACKERS] ANALYZE and index/stats degradation

On Mon, July 2, 2007 18:15, Gregory Stark wrote: >> So I suppose the planner has a good reason to ignore the index at that >> point. I'm assuming that this is something to do with the correlation >> between the index and the column's statistics degrading in some way. > > Best to post "explain ana

[HACKERS] ANALYZE and index/stats degradation

Hi all, I've run into a case where I get bad performance that doesn't sound too hard to solve. Question is: is it worth solving? The situation is this: I have a table that can grow to a large number of rows, then shrink to zero over a large number of quick, consecutive transactions. The primary

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 19:42, Rob Butler wrote: > Do you guys need something PG specific or built into PG? > > ActiveMQ is very nice, speaks multiple languages, protocols and supports a > ton of features. Could you simply use that? > > http://activemq.apache.org/ Looks very nice indeed! Jeroen

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 18:18, Heikki Linnakangas wrote: > Marko Kreen wrote: >> As I understand, JMS does not have a concept >> of transactions, probably also other solutions mentioned before, >> so to use PgQ as backend for them should be much simpler... > > JMS certainly does have the concept of t

Re: [HACKERS] PG-MQ?

On Wed, June 20, 2007 04:45, Chris Browne wrote: > I'm seeing some applications where it appears that there would be > value in introducing asynchronous messaging, ala "message queueing." > > > The "granddaddy" of message queuing systems is IBM's MQ-Seri

Re: [HACKERS] Using the GPU

On Sat, June 9, 2007 07:36, Gregory Stark wrote: > "Billings, John" <[EMAIL PROTECTED]> writes: > >> Does anyone think that PostgreSQL could benefit from using the video >> card as a parallel computing device? I'm working on a project using >> Nvidia's CUDA with an 8800 series video card to handle

Re: [HACKERS] What is the maximum encoding-conversion growth rate, anyway?

On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote: > Thinking more, it striked me that users can define arbitarily growing > rate by using CFREATE CONVERSION. So it seems we need functionality to > define the growing rate anyway. Would it make sense to define just the longest and shortest character

Re: [HACKERS] Oracle indemnifies PostgreSQL on its patents

On Sun, April 1, 2007 01:32, Tom Lane wrote: > The idea of OIN is to have a large patent pool that can be > counter-asserted against anyone who doesn't want to play nice. > Mutual assured destruction in the patent sphere, if you will. And from the participants' point of view, I suppose the big at

Re: [HACKERS] Time-correlated columns in large tables

On Tue, March 6, 2007 03:17, Heikki Linnakangas wrote: > I think you've just described a range-encoded bitmap index. The idea is > to divide the range of valid values into a some smallish number of > subranges, and for each of these boundary values you store a bitmap > where you set the bit repres

[HACKERS] Time-correlated columns in large tables

I'm a bit embarrassed to bring this up here because I don't know much about storage layout and indexing. It's probably a silly notion, but if so, could someone please tell me how and why? First I'll describe the situation that leads me to write this. I'm seeing some performance problems in an ap

Re: [HACKERS] COMMIT NOWAIT Performance Option

On Wed, February 28, 2007 06:59, Jim C. Nasby wrote: > On Tue, Feb 27, 2007 at 05:18:28PM -0500, Bruce Momjian wrote: >> I think we will remove fsync in favor of the new delay, and allow -1 to >> be the same behavior as fsync off. > > Well, presumably we'd still allow fsync for some number of vers

Re: [HACKERS] COMMIT NOWAIT Performance Option

On Tue, February 27, 2007 06:06, Joshua D. Drake wrote: > >> Why do we want this?? Because some apps have *lots* of data and many >> really don't care whether they lose a few records. Honestly, I've met >> people that want this, even after 2 hours of discussion and >> understanding. Plus probably l

[HACKERS] Cosmetic note: hit rates in logs

Just noticed a small cosmetic point in the logs when logging statement performance data: if a statement accesses 0 blocks, the "hit rate" is given as 0%. I can see that that makes sense mathematically--insofar as 0/0 makes mathematical sense at all--but wouldn't it be more helpful to represent thi

Re: [HACKERS] Missing directory when building 8.2.3-base

On Tue, February 13, 2007 01:45, Peter Eisentraut wrote: > Most of the core team is convinced that the postgresql-foo tarballs are > useless, but Marc insists on keeping them. But since they are nearly > useless, no one tests them, so it is not surprising that they don't > work. Well, hurray for

[HACKERS] Missing directory when building 8.2.3-base

I built the "-base" version of 8.2.3 today, for installation at a company I'm helping out. The build (and later, the installation) gave me an error about a missing directory "test/regress". IIRC I downloaded ftp://ftp.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.3/postgresql-base-8.2.3.ta

Re: [HACKERS] PQencryptPassword() and encoding

On Wed, December 20, 2006 11:08, Tom Lane wrote: > "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes: >> Probably a silly question, but better safe than sorry: >> AFAICS there's no way for PQencryptPassword() to see what encoding >> applies. Are we quite

[HACKERS] PQencryptPassword() and encoding

Probably a silly question, but better safe than sorry: AFAICS there's no way for PQencryptPassword() to see what encoding applies. Are we quite sure that that is not a problem? Or are passwords ASCII-only? Jeroen ---(end of broadcast)--- TIP 5

Re: [HACKERS] Optimizing prepared statements

On Mon, September 4, 2006 23:03, Tom Lane wrote: > Ah. I think you're confusing the spectators by using "predict" when you > should say "match". You're looking for previously generated plans that > have assumed parameter values matching the current query --- saying that > the plan "predicts" a p

Re: [HACKERS] Optimizing prepared statements

On Mon, September 4, 2006 03:56, Gregory Stark wrote: > Thanks, that cleared things up enormously. I'm trying to figure how it > would > react to some of the queries I've written in the past. In particular I'm > thinking of queries like > > WHERE (? OR category = ?) > AND (? OR cost < ?) > AND

Re: [HACKERS] Optimizing prepared statements

On Sun, September 3, 2006 23:52, Tom Lane wrote: > What exactly do you mean by "optimize away a parameter"? The way you > described the mechanism, there are no parameters that are "optimized > away", you've merely adjusted selectivity predictions using some assumed > values. I'm using "optimized

Re: [HACKERS] Optimizing prepared statements

On Sun, September 3, 2006 23:28, Jeroen T. Vermeulen wrote: > On Sun, September 3, 2006 21:52, Gregory Stark wrote: >> I read that but apparently I misunderstood it since it would not have >> been >> doable the way I understood it. I thought you wanted the predictor bits &

Re: [HACKERS] Optimizing prepared statements

On Sun, September 3, 2006 21:52, Gregory Stark wrote: > I read that but apparently I misunderstood it since it would not have been > doable the way I understood it. I thought you wanted the predictor bits to > correspond to particular plans. If a plan was "wrong" then you marked it > as a > bad gu

Re: [HACKERS] Optimizing prepared statements

On Sun, September 3, 2006 18:41, Gregory Stark wrote: > I'm confused, what exactly are you trying to predict? Whether each > parameter > will be some cached value? Or whether the cached plan was correct? That's described in more detail in a separate thread ("prepared statements considered harmful

[HACKERS] Optimizing prepared statements

I've rigged up a simple simulator for the scheme I described for detecting pseudo-constant parameters to prepared statements. It withstands simple tests, and it neatly picks up cases where some parameters are pseudo-constants and others aren't--even if some of them are more "pseudo" while others a

Re: [HACKERS] Prepared statements considered harmful

On Fri, September 1, 2006 22:14, Gregory Stark wrote: > I think the slow part is trying to figure out whether to count the current > call as a hit or a miss. How do you determine whether the plan you're > running > is the best plan without replanning the query? The question of knowing which plan

Re: [HACKERS] Prepared statements considered harmful

On Fri, September 1, 2006 21:30, Tom Lane wrote: > Yeah. One of the reasons the planner is acceptably fast is that it is > aggressive about discarding candidate plans as soon as they are clearly > inferior to other plans. Tracking multiple plans that might be optimal > under varying assumptions

Re: [HACKERS] Prepared statements considered harmful

On Fri, September 1, 2006 16:53, Martijn van Oosterhout wrote: > Interesting thought. It might be worth trying. But my big question: is > all this testing and counting actually going to be faster than just > replanning? Postgresql's planner is not that slow. In the best case (which of course woul

Re: [HACKERS] Prepared statements considered harmful

On Thu, August 31, 2006 21:41, Phil Frost wrote: >> Is there any kind of pattern at all to this problem? Anything >> recognizable? A few typical pitfalls? > > Frequently I have found preplanning will result in a horrible plan > because it is assumed parameters may be volatile while in practice t

Re: [HACKERS] Prepared statements considered harmful

On Thu, August 31, 2006 18:56, Peter Eisentraut wrote: > With time, it becomes ever clearer to me that prepared SQL statements are > just > a really bad idea. On some days, it seems like half the performance > problems > in PostgreSQL-using systems are because a bad plan was cached somewhere. Is

Re: [HACKERS] [OT] MySQL is bad, but THIS bad?

On Fri, May 19, 2006 13:25, Thomas Hallgren wrote: > If that's really true, then let's create a bidirectional compatibility > layer as a joint > venture with people from the MySQL camp. Should be a win-win situation. I > somehow doubt that > is the case. Important yes. But "just as important"? No

Re: [HACKERS] Return results for PQexec vs PQexecP*

On Wed, May 17, 2006 19:53, Martijn van Oosterhout wrote: > The main problem with PQexec and co is that they don't really do very > well if a single query produces multiple result sets. I'm not sure if > it's defined whether you get the first or the last. In any case, if you > want all the result

Re: [HACKERS] Pregunta sobre limitar el

On Tue, March 14, 2006 22:14, Paulina Quezada wrote: > Hola, necesito saber con que sentencias sql puedo controlar desde un > trigger > el número de registros a actualizar o a borrar, esto para que desde la > consola no se hagan deletes o updates masivos. Aqui se habla ingles. Jeroen

Re: [HACKERS] Pgfoundry and gborg: shut one down

On Mon, February 20, 2006 11:00, Marc G. Fournier wrote: >> Speaking for libpqxx, my only concern with that is the mailing list. >> Would those have to move to different addresses--or conversely, would a >> forced migration make it much easier to move *all* GBorg mailing lists >> to >> pgFoundry a

Re: [HACKERS] Pgfoundry and gborg: shut one down

On Sun, February 19, 2006 05:10, Bruce Momjian wrote: > I don't care what direction we go, just kill one. Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all

Re: [HACKERS] ROLLBACK triggers?

On Mon, January 23, 2006 16:35, Daisuke Maki wrote: > > I'm currently trying to embed Senna full text search engine > (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by > using triggers (implemented in C) to cause an update to senna's index at > various points. > > This seemed to

Re: [HACKERS] Old interfaces directory in CVS tree?

On Tue, November 8, 2005 00:02, Marc G. Fournier wrote: > On Mon, 7 Nov 2005, Andrew Dunstan wrote: >> Oh, the top level interfaces directory. I misunderstood. Why is anybody >> checking that out at all? Are we keeping it for historical purposes? I think the person in question was doing a regula

Re: [HACKERS] Old interfaces directory in CVS tree?

On Sat, Nov 05, 2005 at 09:46:15AM -0500, Andrew Dunstan wrote: > >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

Re: [HACKERS] additional GCC warnings

On Sun, Oct 17, 2004 at 01:50:46PM -0400, Tom Lane wrote: > > -Wdeclaration-after-statement (Recent versions of GCC allow declarations > > and statements to be intermixed in C; enabling this flag would enforce > > the current convention of avoiding this style.) > > Ick. If the default is to a

Re: [HACKERS] profile-guided opt. w/ GCC

On Thu, Sep 30, 2004 at 07:07:27PM +1000, Neil Conway wrote: > I think it would be cool to add support for PGO to PostgreSQL's build > system (for 8.1). There are a lot of situations where PostgreSQL is > compiled once, and then used for weeks or months (compilations for > inclusion in a distro b

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 04:05:26PM -0400, Tom Lane wrote: > Well, I think it would time out quickly --- anyway on the order of > minutes not hours. By hypothesis, the situation you're worried about is > where the backend was unable to send you a COMMIT acknowledgement > message. The kernel is g

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 03:41:24PM -0400, Tom Lane wrote: > >> No, stats_command_string need not be set, only stats_start_collector. > > > BTW, I've got this set (I'm even running as "postgres") but still I get > > the "" message instead of current_query. :( > > It has to be set in the backend y

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote: > No, stats_command_string need not be set, only stats_start_collector. BTW, I've got this set (I'm even running as "postgres") but still I get the "" message instead of current_query. :( Jeroen ---(end of bro

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote: > No, because of the reporting delay. I would recommend waiting for the > backend's row in pg_stat_activity to disappear entirely. Under normal > circumstances that should occur quickly. If there's a communications > problem, it might t

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote: > I don't see any reason for guesswork. Remember the PID of the backend > you were connected to. On reconnect, look in pg_stat_activity to see if > that backend is still alive; if so, sleep till it's not. Then check to > see if your tra

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote: > I don't see any reason for guesswork. Remember the PID of the backend > you were connected to. On reconnect, look in pg_stat_activity to see if > that backend is still alive; if so, sleep till it's not. Then check to > see if your tra

Re: [HACKERS] transaction idle timeout in 7.4.5 and 8.0.0beta2

On Fri, Sep 17, 2004 at 08:47:02AM +0200, Szima G?bor wrote: > I was implement the "transaction idle timeout" function in PostgreSQL > (version 7.4.5 and 8.0.0beta2) It sounds interesting to me (for use in libpqxx, the C++ API), but perhaps for a slightly unusual reason. When a connection to th

Re: [HACKERS] WIN1250 as server encoding

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 wi

Re: [HACKERS] devx article

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: "MyS

Re: [HACKERS] COPY with column headings

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

Re: [HACKERS] COPY with column headings

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] try/catch macros for Postgres backend

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 thoug

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

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 t

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

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: [Re] Re: [HACKERS] PREPARE and transactions

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: subtransactions and FETCH behaviour (was Re: [HACKERS] PREPARE and transactions)

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 com

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

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

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

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

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

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, ye

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

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 v

Re: [HACKERS] LinuxTag wrapup

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

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

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

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

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: [HACKERS] LinuxTag wrapup

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 ab

Re: [HACKERS] PREPARE and transactions

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 cas

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

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/

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

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. A

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

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 transact

Re: [HACKERS] Nested Transactions, Abort All

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

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 Th

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

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

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 behavio

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

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

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: [Re] Re: [HACKERS] PREPARE and transactions

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 g

Re: [HACKERS] Default libpq service

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 de

Re: [HACKERS] PREPARE and transactions

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 w

Re: [HACKERS] PREPARE and transactions

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 s

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

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 probabl

Re: [HACKERS] PREPARE and transactions

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 >

Re: [HACKERS] PREPARE and transactions

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, ex

[HACKERS] PREPARE and transactions

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] New COPY commands in libpq

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 t

Re: [HACKERS] New COPY commands in libpq

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); >

Re: [HACKERS] 7.5 beta version

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 double"s on some compilers which could be 80 bit. Actually

Re: [HACKERS] 7.5 beta version

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

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

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 t

Re: [HACKERS] 7.5 beta version

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 cas

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

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: [pgsql-www] [HACKERS] The Name Game: postgresql.net vs.

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: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

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 mak

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

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 Post

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

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 thi

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

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.pgfound

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

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) poi

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

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 tr

  1   2   >