Re: [HACKERS] DROP DATABASE vs patch to not remove files right away

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Patch attached that does the three changes we've talked about:' - make ForgetDatabaseFsyncRequests forget unlink requests as well - make rmtree() not fail on ENOENT - force checkpoint on in dropdb on all platforms This looks fine a

Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

On Thu, Apr 17, 2008 at 03:18:54PM +0200, Peter Eisentraut wrote: > I think the bottom line is just that having statement_timeout a global > setting > is stupid for a variety of reasons (dump, restore, vacuum, locks, incidental > delays) that we should discourage it (or prevent it, as proposed e

Re: [HACKERS] get rid of psql welcome message

On Fri, 18 Apr 2008 00:42:06 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > I'm +1 for cutting that down to a single line. I don't care one way > or the other about providing a .psqlrc option to suppress it > altogether. Peter do you want to run with this, or would you mind if I worked up a patch?

Re: [HACKERS] get rid of psql welcome message

Robert Treat <[EMAIL PROTECTED]> writes: > I think it's getting overlooked because most people don't deal with it, but I > really think we need to keep the SSL info as is. Well, in general the *variable* parts of the banner were all put there because of fairly urgent need, and I'd resist removing

Re: [HACKERS] Lessons from commit fest

Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Greg Smith wrote: > >> Scraping that HTML seems like it would be pretty straightforward. > > > It's awfully incomplete. Bruce said to me the other day on IM that the > > list he was getting with the Linux version of find_typedef was

Re: [HACKERS] get rid of psql welcome message

On Fri, 18 Apr 2008 00:21:58 -0400 Robert Treat <[EMAIL PROTECTED]> wrote: > > We could just do: > > > > psql 8.1.10 - postgresql server version 8.1.10 > > > > Type: \h for SQL help, \? for psql help, \q to quit > > > > postgres=# > > I think it's getting overlooked because most people don't deal

Re: [HACKERS] get rid of psql welcome message

On Thursday 17 April 2008 12:04, Joshua D. Drake wrote: > On Thu, 17 Apr 2008 11:11:58 -0400 > > Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > Brendan Jurd wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote: > > >> Peter Ei

Re: [HACKERS] Lessons from commit fest

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Greg Smith wrote: >> Scraping that HTML seems like it would be pretty straightforward. > It's awfully incomplete. Bruce said to me the other day on IM that the > list he was getting with the Linux version of find_typedef was something > like 2800 symbo

Re: [HACKERS] Lessons from commit fest

Greg Smith wrote: > On Fri, 18 Apr 2008, Gregory Stark wrote: > >> The reason I was asking these questions was because I was thinking >> about how hard it would be to generate the list from a textual analysis >> instead of using object files. > > Is there some reason I don't understand why the li

Re: [HACKERS] Lessons from commit fest

On Fri, 18 Apr 2008, Gregory Stark wrote: The reason I was asking these questions was because I was thinking about how hard it would be to generate the list from a textual analysis instead of using object files. Is there some reason I don't understand why the listing doyxgen creates isn't go

Re: [HACKERS] Lessons from commit fest

Gregory Stark wrote: But if we're still doing object file analysis on the build farm and it's easy to add typedefs manually then perhaps there's not much effort saved by having such a tool. I think it would be possible to write but it wouldn't really be easy. You have to parse just enough C to

Re: [HACKERS] Lessons from commit fest

"Tom Lane" <[EMAIL PROTECTED]> writes: "Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Tom Lane" <[EMAIL PROTECTED]> writes: > >> 1) I take it we feel safe guaranteeing that we won't use any fancy macros >>inside typedefs. So no '#define pgtype(x) _pg_##

Re: [HACKERS] Plan targetlists in EXPLAIN output

PFC wrote: > Plan = Tree > Tree = XML If you want to propose a DTD I'm sure there would be many people interested. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] pgsql: Fix a couple of oversights associated with the "physical tlist"

[resending because the first went to -committers which is kind of bogus] "Tom Lane" <[EMAIL PROTECTED]> writes: > Log Message: > --- > Fix a couple of oversights associated with the "physical tlist" optimization: > we had several code paths where a physical tlist could be used for the in

Re: [HACKERS] Lessons from commit fest

* Tom Lane <[EMAIL PROTECTED]> [080417 20:47]: > Right, but if the only use is inside #ifdef __BRAND_X_PLATFORM__, > the only way for the proposed toolchain to extract that usage is > if someone runs it on BRAND_X_PLATFORM. > > Of course, for seldom-used platforms maybe we don't care that much.

Re: [HACKERS] Lessons from commit fest

Aidan Van Dyk <[EMAIL PROTECTED]> writes: > * Tom Lane <[EMAIL PROTECTED]> [080417 20:11]: >> Ouch, that's a real good point. Maybe a certain amount of platform >> dependence is inevitable. > I don't get it. If they are used as typedefs *anywhere* in the PG > source, they're needed in the typede

Re: [HACKERS] Cross-field statistics

On Apr 17, 2008, at 12:22 PM, Gregory Stark wrote: "Decibel!" <[EMAIL PROTECTED]> writes: For each field that isn't already in a set of field groupings * Sort sample rows on that field * Calculate correlation for all other fields * If there are other fields that have a correlation to this so

Re: [HACKERS] Lessons from commit fest

* Tom Lane <[EMAIL PROTECTED]> [080417 20:11]: > > 3) How would this work with typedefs which come from system or library > >includes? > > Ouch, that's a real good point. Maybe a certain amount of platform > dependence is inevitable. I don't get it. If they are used as typedefs *anywhere*

Re: [HACKERS] RFD: hexstring(n) data type

Gregory Stark <[EMAIL PROTECTED]> writes: > However bytea has an inconvenient string representation. Really I would prefer > if bytea were *always* read and written in hex format. Yeah, the escaping rule is a mess: hard to work with and even less storage-efficient than hex would be. > We could ha

Re: [HACKERS] Lessons from commit fest

Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> That would certainly be better than the current approach, since >> presumably it would cover not only Windows but the other >> conditionally-compiled stuff that Bruce chooses not to compile on >> his own machine.

Re: [HACKERS] DROP DATABASE vs patch to not remove files right away

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Patch attached that does the three changes we've talked about:' > - make ForgetDatabaseFsyncRequests forget unlink requests as well > - make rmtree() not fail on ENOENT > - force checkpoint on in dropdb on all platforms This looks fine as far as it

Re: [HACKERS] RFD: hexstring(n) data type

I don't think we should define types based on how they print. We should define types based on what they contain. bytea is a perfectly good datatype for storing binary data, though perhaps we could use a bytea(n) for fixed size binary data. However bytea has an inconvenient string representation.

Re: [HACKERS] Lessons from commit fest

"Tom Lane" <[EMAIL PROTECTED]> writes: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> I have been thinking of pursuing your suggestion of having it as a >> buildfarm option. We could provide a SOAP interface to collect the >> typedefs and then consolidate them and put them in CVS. We could eve

Re: [HACKERS] Plan targetlists in EXPLAIN output

On Thu, 17 Apr 2008 20:42:49 +0200, Simon Riggs <[EMAIL PROTECTED]> wrote: On Thu, 2008-04-17 at 12:34 -0400, Tom Lane wrote: I'm tempted to propose redefining the currently-nearly-useless EXPLAIN VERBOSE option as doing this. Yes please. Sounds like a good home for other useful things al

Re: [HACKERS] count(*) performance improvement ideas

My wife has a snake phobia, besides, I've just started learning Scala. Just had a look at Scala, it looks nice. Slightly Lispish (like all good languages)... txid_current() No... hold on, it is per session, and a session can't have two or more transactions active at once can it?

Re: [HACKERS] Plan targetlists in EXPLAIN output

On Thu, 17 Apr 2008, Tom Lane wrote: For debugging the planner work I'm about to do, I'm expecting it will be useful to be able to get EXPLAIN to print the targetlist of each plan node, not just the quals (conditions) as it's historically done. I've heard that some of the academic users of Pos

Re: [HACKERS] get rid of psql welcome message

[EMAIL PROTECTED] (Stephen Frost) writes: > * Peter Eisentraut ([EMAIL PROTECTED]) wrote: >> Around >> it >> was proposed to truncate the psql welcome screen. What do you think about >> that? > > I'd recommend an option in .psq

Re: [HACKERS] pg_terminate_backend() issues

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> The closest thing I can think of to an automated test is to run repeated > >> sets of the parallel regression tests, and each time SIGTERM a randomly > >> chosen backend at a randomly chosen time. Then see if anyt

Re: [HACKERS] count(*) performance improvement ideas

> > The big gotcha is that these are all non-transactional > > : if you rollback, > > GD and SD stay the same, and when you issue a query, you can > > assume the > > state of SD and GD is random (due to previous queries) unless you > > initialize them to a known value. > > Using txid_c

Re: [HACKERS] get rid of psql welcome message

On Thu, 17 Apr 2008 09:30:04 -0400 Stephen Frost wrote: > * Peter Eisentraut ([EMAIL PROTECTED]) wrote: > > Around > > it > > was proposed to truncate the psql welcome screen. What do you think about > > that? > > I'd recomme

Re: [HACKERS] get rid of psql welcome message

On Thu, 17 Apr 2008 15:58:10 +0200 Peter Eisentraut wrote: > Mike Aubury wrote: > > Am I missing something.. > > > > $ psql -q testdb > > testdb=# > > This also quiets out a few other unrelated things. Like all \timing messages *grumble* -- Andreas 'ads' Scherba

Re: [HACKERS] count(*) performance improvement ideas

PFC wrote > <[EMAIL PROTECTED]> wrote: > > I don't know plpythonu (nor python), just read a few docs now: > > Learn Python, it is a really useful language ;) My wife has a snake phobia, besides, I've just started learning Scala. > There is no sharing between processes, so > -

Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Greg Sabino Mullane wrote: A use case would be dumping a large table and wanting to load it into the database, but wanting to stop the job if it is still running an hour from now, when a maintenance window is scheduled to start. statement_timeout is pretty useless for that purpose, because it l

Re: [HACKERS] DROP DATABASE vs patch to not remove files right away

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests causes PendingUnlinkEntrys for the doomed DB to be thrown away too. Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this st

Re: [HACKERS] RFD: hexstring(n) data type

I am confused how a hex type is any better than using the 'hex' decode() format we already support: test=> select decode('5476', 'hex'); decode Tv (1 row) --- Dawid Kuroczk

Re: [HACKERS] get rid of psql welcome message

Simon Riggs wrote: On Thu, 2008-04-17 at 09:30 -0400, Stephen Frost wrote: * Peter Eisentraut ([EMAIL PROTECTED]) wrote: Around it was proposed to truncate the psql welcome screen. What do you think about that? I'd recommend

Re: [HACKERS] Plan targetlists in EXPLAIN output

On Thu, 2008-04-17 at 12:34 -0400, Tom Lane wrote: > I'm tempted to propose redefining the currently-nearly-useless > EXPLAIN VERBOSE option as doing this. Yes please. Sounds like a good home for other useful things also. I'd like to have an EXPLAIN mode that displayed the plan without *any* ch

Re: [HACKERS] Lessons from commit fest

[EMAIL PROTECTED] (Tom Lane) writes: > Chris Browne <[EMAIL PROTECTED]> writes: >> Would it be a terrible idea to... >> >> - Draw the indent code from NetBSD into src/tools/pgindent > > I am not real eager to become maintainers of our own indent fork, which > is what you propose. (Just for starte

Re: [HACKERS] MERGE SQL Statement

[EMAIL PROTECTED] (Simon Riggs) writes: >> Should there be a new rule option? ie. ON MERGE rules ? > > Maybe, but not as part of this project. That seems to warrant a bit of elaboration... If we're running a MERGE, and it performs an INSERT or UPDATE of a particular tuple in(to) a particular ta

Re: [HACKERS] Plan targetlists in EXPLAIN output

Gregory Stark <[EMAIL PROTECTED]> writes: > Or is it estimating the width based on the belief that only the thousand > column is actually going to be emitted? Right. The width is used to estimate how much space would be needed for, eg, sorting or hashing the plan node's output. In any case where

Re: [HACKERS] Plan targetlists in EXPLAIN output

"Tom Lane" <[EMAIL PROTECTED]> writes: > I'm not convinced. The width is often useful to understand why the > planner did something (eg, chose a hash plan or not). The exact > contents of the targetlist are usually not nearly as interesting. I've never seen a single post on any of the lists whe

Re: [HACKERS] Lessons from commit fest

Andrew Dunstan <[EMAIL PROTECTED]> writes: > I have been thinking of pursuing your suggestion of having it as a > buildfarm option. We could provide a SOAP interface to collect the > typedefs and then consolidate them and put them in CVS. We could even do > it per release. That would include Win

Re: [HACKERS] Lessons from commit fest

Gregory Stark wrote: > The only thing is that if the whole point is to have patch submitters run > pgindent on their own added code it won't work since their own code will be > precisely the code with the missing typedefs. How easy is it to manually add a > handful of typedefs to the list? The li

Re: [HACKERS] Lessons from commit fest

Andrew Dunstan wrote: > I have been thinking of pursuing your suggestion of having it as a > buildfarm option. We could provide a SOAP interface to collect the > typedefs and then consolidate them and put them in CVS. We could even do > it per release. That would include Windows, although on

Re: [HACKERS] Plan targetlists in EXPLAIN output

Gregory Stark <[EMAIL PROTECTED]> writes: > EXPLAIN VERBOSE is indeed ridiculous. There are other ways to get that printout, too, if you really do need it. > IMHO You could also move "width" to VERBOSE while you're at it. In fact you'll > probably want width in precisely the same cases where you

Re: [HACKERS] Lessons from commit fest

"Alvaro Herrera" <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: > >> Based on that reaction I am not going to bother uploading my copy of the >> typedefs. > > Please reconsider. Not having pgindent work at all is not better than > it working "only" 98%. I think I'm rescinding my objection to

Re: [HACKERS] Lessons from commit fest

Alvaro Herrera wrote: Bruce Momjian wrote: Based on that reaction I am not going to bother uploading my copy of the typedefs. Please reconsider. Not having pgindent work at all is not better than it working "only" 98%. I have been thinking of pursuing your suggestion of havin

Re: [HACKERS] Lessons from commit fest

Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Based on that reaction I am not going to bother uploading my copy of the > > typedefs. > > Please reconsider. Not having pgindent work at all is not better than > it working "only" 98%. That's what I thought, but Tom thinks my list is unaccepta

Re: [HACKERS] Plan targetlists in EXPLAIN output

"Tom Lane" <[EMAIL PROTECTED]> writes: > For debugging the planner work I'm about to do, I'm expecting it will be > useful to be able to get EXPLAIN to print the targetlist of each plan > node, not just the quals (conditions) as it's historically done. My > first instinct is just to stick in the

Re: [HACKERS] Lessons from commit fest

Bruce Momjian wrote: > Based on that reaction I am not going to bother uploading my copy of the > typedefs. Please reconsider. Not having pgindent work at all is not better than it working "only" 98%. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Rep

Re: [HACKERS] Cross-field statistics

"Decibel!" <[EMAIL PROTECTED]> writes: > For each field that isn't already in a set of field groupings > * Sort sample rows on that field > * Calculate correlation for all other fields > * If there are other fields that have a correlation to this sort order over > some threshold, save them alo

Re: [HACKERS] Lessons from commit fest

Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > What are we going to do about the duality of Windows vs. non-Windows? > > Perhaps we could collect typedefs generated on the buildfarm. > > I think it's really not acceptable that pgindent misformats Windows-only > code (or any other

Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Sorry if I missed it in the original thread, but what is the > use case you have in mind? A use case would be dumping a large table and wanting to load it into the database, but wanting to stop the job if it is still running an hour from now,

Re: [HACKERS] get rid of psql welcome message

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > We could just do: > > psql 8.1.10 - postgresql server version 8.1.10 > > Type: \h for SQL help, \? for psql help, \q to quit Best idea yet. I also still like the .psqlrc no-splash option, no reason we can't do both. - -- Greg Sabino Mullane

[HACKERS] Plan targetlists in EXPLAIN output

For debugging the planner work I'm about to do, I'm expecting it will be useful to be able to get EXPLAIN to print the targetlist of each plan node, not just the quals (conditions) as it's historically done. My first instinct is just to stick in the code under a debugging #ifdef, but I wonder if a

[HACKERS] Multiline privileges in \z

Hi hackers, It occurred to me that psql's \z command could benefit from the addition of some newlines. With any more than one grantee per object, the output of \z rapidly becomes extremely wide, and very hard to read. I'd like to split the output onto one line per grantee. So, instead of this:

Re: [HACKERS] new field content lost

Gaetano Mendola <[EMAIL PROTECTED]> writes: > since long time I have implemented a materialized view, today I had to add a > new field and I faced the following (I believe) bug. > The bug can be replicated on a 8.2.7 Cached plan for the function's UPDATE. Should work okay in 8.3 ...

[HACKERS] new field content lost

Hi all, since long time I have implemented a materialized view, today I had to add a new field and I faced the following (I believe) bug. The bug can be replicated on a 8.2.7 -- SETUP create table test (a integer, b integer); create table test_trigger (a integer); CREATE OR REPLACE FUNCTION tri

Re: [HACKERS] get rid of psql welcome message

On Thu, 17 Apr 2008 11:11:58 -0400 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > Brendan Jurd wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote: > > > >> Peter Eisentraut writes: > >> > Around it > >> > was proposed to

Re: [HACKERS] count(*) performance improvement ideas

Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I thought about this in the shower just now, and ISTM that if we want to >> turn this into an actual feature rather than a kluge, there needs to be >> some sort of "define variable" command that sets up a custom variable >> and specifies i

Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Heikki Linnakangas wrote: >> Sorry if I missed it in the original thread, but what is the use case >> you have in mind? > I think the bottom line is just that having statement_timeout a global > setting > is stupid for a variety of reasons (dump, re

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory

Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > Is this so? This happened to me the other day (hence the question about > having COPY note failure earlier) because the disk filled up. I was > confused because du showed nothing. Eventually I did an lsof and found > the postgres backend had a la

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory

On Thu, Apr 17, 2008 at 04:03:18PM +0300, Heikki Linnakangas wrote: > They do clean up on abort or SIGTERM. If you experience a sudden power > loss, or kill -9 while CLUSTER or REINDEX is running, they will leave > behind dangling files, but that's a different problem. It's not limited > to util

Re: [HACKERS] get rid of psql welcome message

Brendan Jurd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote: Peter Eisentraut writes: > Around it > was proposed to truncate the psql welcome screen. What do you think about > that? Personally. I'm very seriously against losin

Re: [HACKERS] get rid of psql welcome message

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 12:36 AM, Tom Lane wrote: > Peter Eisentraut writes: > > Around it > > was proposed to truncate the psql welcome screen. What do you think about > > that? > > Personally. I'm very seriously against losing the version num

Re: [HACKERS] Lessons from commit fest

Alvaro Herrera <[EMAIL PROTECTED]> writes: > What are we going to do about the duality of Windows vs. non-Windows? > Perhaps we could collect typedefs generated on the buildfarm. I think it's really not acceptable that pgindent misformats Windows-only code (or any other part of the code that Bruce

[HACKERS] Cross-field statistics

I just had an idea about how to create cross-field statistics, which could greatly improve the quality of estimates involving multiple conditions on one table. This is rather arm-wavy, but I wanted to at least get the idea out... If we built a table via CREATE TABLE moo AS SELECT i, i*2 AS

Re: [HACKERS] get rid of psql welcome message

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Around it > was proposed to truncate the psql welcome screen. What do you think about > that? Personally. I'm very seriously against losing the version number banner. I could do wi

Re: [HACKERS] runtime error on SPGIST, needed help

Hello and really thanks for the answer, I found the solution for the problem also thanks to the gdb debugger. My problem was a SegmentationFault runtime error due to a little tricky: the function SPGIST_FUNCTION(pquad_equals_op) is defined as follows #define SPGIST_FUNCTION(name) extern "C" Datum

Re: [HACKERS] Lessons from commit fest

Bruce Momjian wrote: > The source code is the same for both Unix and Windows but you are right > some typedefs are only visible on windows. I think most are from > EXEC_BACKEND so compiling with/without that should help but then you > have to merge the typedef lists, of course. The source code i

Re: [HACKERS] get rid of psql welcome message

On Thu, 2008-04-17 at 09:30 -0400, Stephen Frost wrote: > * Peter Eisentraut ([EMAIL PROTECTED]) wrote: > > Around > > it > > was proposed to truncate the psql welcome screen. What do you think about > > that? > > I'd recommen

Re: [HACKERS] MERGE SQL Statement

On Thu, 2008-04-17 at 07:31 +0100, Simon Riggs wrote: > > > * MERGE will perform a left outer join between source on left and target > > > on right. There must be no more than 1 row from table-ref for each row > > > in the table. Each row in the table can only be updated once during each > > > MER

Re: [HACKERS] Lessons from commit fest

Alvaro Herrera wrote: > Bruce Momjian wrote: > > Magnus Hagander wrote: > > > > IIRC, last time I tried it, the failure was because I couldn't get it > > > to build the proper typedefs. Any chance you could just put a regularly > > > updated typedefs file somewhere that I could wget down? > > > >

Re: [HACKERS] Lessons from commit fest

Magnus Hagander wrote: > > > > Also I can put up a web page where you can upload or email your C > > > > file and get a formatted version back. > > > > > > IIRC, last time I tried it, the failure was because I couldn't get > > > it to build the proper typedefs. Any chance you could just put a > >

Re: [HACKERS] Lessons from commit fest

Bruce Momjian wrote: > Magnus Hagander wrote: > > IIRC, last time I tried it, the failure was because I couldn't get it > > to build the proper typedefs. Any chance you could just put a regularly > > updated typedefs file somewhere that I could wget down? > > Have you tried the CVS version? It s

Re: [HACKERS] get rid of psql welcome message

A. Kretschmer wrote: > I'd vote No, because i see very often on #irc people asking something > like 'how can i see the table definition' or other, and in this cases > it's easy to say: hey dude, read the fine welcome message *g* I take this as evidence that the welcome message has limited use in p

Re: [HACKERS] get rid of psql welcome message

Mike Aubury wrote: > Am I missing something.. > > $ psql -q testdb > testdb=# This also quiets out a few other unrelated things. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lessons from commit fest

Bruce Momjian wrote: > Magnus Hagander wrote: > > Bruce Momjian wrote: > > > Bruce Momjian wrote: > > > > Tom Lane wrote: > > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > > I am reviewing the psql wrap patch and just used pgindent > > > > > > today to clean it up. (pgindent did not ad

Re: [HACKERS] Lessons from commit fest

Magnus Hagander wrote: > Bruce Momjian wrote: > > Bruce Momjian wrote: > > > Tom Lane wrote: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > I am reviewing the psql wrap patch and just used pgindent today > > > > > to clean it up. (pgindent did not add any extra spacing > > > > > chang

Re: [HACKERS] get rid of psql welcome message

am Thu, dem 17.04.2008, um 14:39:43 +0200 mailte Peter Eisentraut folgendes: > Around it > was proposed to truncate the psql welcome screen. What do you think about > that? > > Personally, I'd get rid of it all, because it get

Re: [HACKERS] get rid of psql welcome message

Am I missing something.. $ psql -q testdb testdb=# And - if you're using bash - you could just $ alias "psql=psql -q" $ psql testdb testdb=# On Thursday 17 April 2008 13:39:43 Peter Eisentraut wrote: > Around > it was pro

Re: [HACKERS] get rid of psql welcome message

Peter Eisentraut wrote: Around it was proposed to truncate the psql welcome screen. What do you think about that? Personally, I'd get rid of it all, because it gets boring after about three uses, so that we would be at [EM

Re: [HACKERS] get rid of psql welcome message

* Peter Eisentraut ([EMAIL PROTECTED]) wrote: > Around it > was proposed to truncate the psql welcome screen. What do you think about > that? I'd recommend an option in .psqlrc to disable it, if possible. That would be in line

Re: [HACKERS] Timely reporting of COPY errors

* Martijn van Oosterhout ([EMAIL PROTECTED]) wrote: > On Wed, Apr 16, 2008 at 05:22:17PM -0400, Tom Lane wrote: > > Even if we had some way of letting the application notice that the copy > > had already failed, I don't see that psql could do very much with it, > > at least not for COPY FROM STDIN.

Re: [HACKERS] get rid of psql welcome message

On Thu, 2008-04-17 at 14:39 +0200, Peter Eisentraut wrote: > Personally, I'd get rid of it all, because it gets boring after about three > uses, so that we would be at Many people I speak to use Postgres every 6 months or so, so changes like this make them think its broke when its not. I'd vote

Re: [HACKERS] get rid of psql welcome message

Peter Eisentraut wrote: > Around > > it was proposed to truncate the psql welcome screen. What do you > think about that? > > Personally, I'd get rid of it all, because it gets boring after about > three uses, so that we would be

Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Heikki Linnakangas wrote: > Sorry if I missed it in the original thread, but what is the use case > you have in mind? I think the bottom line is just that having statement_timeout a global setting is stupid for a variety of reasons (dump, restore, vacuum, locks, incidental delays) that we should

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places whereSIGTERM exit couldleave shared memory

Heikki Linnakangas wrote: Alvaro Herrera wrote: Heikki Linnakangas wrote: Alvaro Herrera wrote: Tom Lane wrote: Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. I wonder if

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places whereSIGTERM exit couldleave shared memory

Alvaro Herrera wrote: Heikki Linnakangas wrote: Alvaro Herrera wrote: Tom Lane wrote: Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. I wonder if we could use this mechanism f

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory

Heikki Linnakangas wrote: > Alvaro Herrera wrote: >> Tom Lane wrote: >> >>> Also use this method >>> for createdb cleanup --- that wasn't a shared-memory-corruption problem, >>> but SIGTERM abort of createdb could leave orphaned files lying around. >> >> I wonder if we could use this mechanism for

Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory

Alvaro Herrera wrote: Tom Lane wrote: Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. I wonder if we could use this mechanism for cleaning up in case of failed CLUSTER, REINDEX

Re: [HACKERS] Lessons from commit fest

Peter Eisentraut wrote: > Martijn van Oosterhout wrote: > > I doubt it, indent doesn't know nearly enough C to be able to anything > > other than adjust whitespace. It surely won't remove braces... > > I faintly recall that it does or at least did at some point. It used to remove braces around si

Re: [HACKERS] Lessons from commit fest

Martijn van Oosterhout wrote: > I doubt it, indent doesn't know nearly enough C to be able to anything > other than adjust whitespace. It surely won't remove braces... I faintly recall that it does or at least did at some point. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in P

On Mon, 2008-03-31 at 18:21 +, sanjay sharma wrote: > overkill. Compliance requirement for storing private data arises from > each organizations own declared privacy policies and statutory bodies > like privacy commissioners and other privacy watchdogs. These > standards are not as strict as PC

[HACKERS] get rid of psql welcome message

Around it was proposed to truncate the psql welcome screen. What do you think about that? Personally, I'd get rid of it all, because it gets boring after about three uses, so that we would be at [EMAIL PROTECTED]:~$ psql test

[HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit could leave shared memory

Tom Lane wrote: > Also use this method > for createdb cleanup --- that wasn't a shared-memory-corruption problem, > but SIGTERM abort of createdb could leave orphaned files lying around. I wonder if we could use this mechanism for cleaning up in case of failed CLUSTER, REINDEX or the like. I thi

Re: [HACKERS] Lessons from commit fest

Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > I am reviewing the psql wrap patch and just used pgindent today > > > > to clean it up. (pgindent did not add any extra spacing > > > > changes.) Patch reviewers should probably

Re: [HACKERS] count(*) performance improvement ideas

On Thu, 17 Apr 2008 02:48:37 +0200, Stephen Denne <[EMAIL PROTECTED]> wrote: PFC wrote: Let's try this quick & dirty implementation of a local count-delta cache using a local in-memory hashtable (ie. {}). CREATE OR REPLACE FUNCTION update_count( key TEXT, delta INTEGER ) RETURNS INTEGER

Re: [HACKERS] Lessons from commit fest

On Thu, Apr 17, 2008 at 09:11:12AM +0300, Heikki Linnakangas wrote: > Something like this: > > if (foo) > { > do something; > do something else; > } > ... > > -> > > if (foo) > do something; > do something else; > ... I doubt it, indent doesn't know nearly enough C to be able