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
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 as
On Thu, Apr 17, 2008 at 11:48:41AM -0400, Tom Lane wrote:
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.
Tom Lane wrote:
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
Tom Lane wrote:
[ click click... ] A quick grep counts 2154 occurrences of the word
'typedef' in our tree. Some of them are no doubt false hits
(documentation etc), but on the other hand you need to add typedefs
coming from system headers.
doxygen's 200-some is clearly an order of
Bruce Momjian wrote:
pgindent is probably 97% optimal. Getting a better typedef list will
change that to perhaps 97.2% optimal. There is a lot of discussion
happening to try to get that 0.2%. :-O
If I'm allowed to make my own guesses I'd say pgindent is at about 90%
currently and we could
Alvaro Herrera wrote:
Bruce Momjian wrote:
pgindent is probably 97% optimal. Getting a better typedef list will
change that to perhaps 97.2% optimal. There is a lot of discussion
happening to try to get that 0.2%. :-O
If I'm allowed to make my own guesses I'd say pgindent is at
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
Tom Lane wrote:
Well, in general the *variable* parts of the banner were all put there
because of fairly urgent need, and I'd resist removing them. It's the
unchanging boilerplate that seems open to debate.
I'm +1 for cutting that down to a single line. I don't care one way or
the other
Alvaro Herrera wrote:
Yes they are useful. As a new patcher, where should I look for coding
standards? How about a little FAQ at the
top of the CVS source tree?
The developer's FAQ is supposed to contain this kind of thing, but I
think it's rather thin on actual details. (Some time
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like int and float but presumably
we would know if that caused any
On Friday 18 April 2008 00:24, Joshua D. Drake wrote:
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
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like int and float but
Andrew Dunstan [EMAIL PROTECTED] writes:
It looks like Windows will blow all our existing numbers out of the
water. Here's a list generated from Cygwin with 6088 symbols. I'm
working on getting a similar list from MinGW.
Hmm, your toolset must be listing all typedefs present in the header
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
It looks like Windows will blow all our existing numbers out of the
water. Here's a list generated from Cygwin with 6088 symbols. I'm
working on getting a similar list from MinGW.
Hmm, your toolset must be listing all
I wrote:
I've been thinking about how to improve the planner's poor handling of
variables in outer-join situations.
...
I think the basic solution for this is that upper levels of the plan tree
should refer to the nullable output columns of an outer join using
alias Vars that name the join
Andrew Dunstan wrote:
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like
Andrew Dunstan wrote:
And here are the 7625 from MinGW.
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dawn_batdt=2008-04-19%20004514stg=typedefs
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use neither ... My guess is that they are used in the system DLLs or
something like that.
Andrew Dunstan wrote:
Skimming the output it does have things like int and float but
presumably
we would know if that caused any problem, they wouldn't inflate the numbers
much.
2800 does seem a bit high. My buildfarm member dungbeetle just found 2482
on a
build that is only
Bruce Momjian [EMAIL PROTECTED] writes:
As soon as you have a stable typedef file we can all use please update
the pgindent README to point to that URL. Keep the instructions of how
to create it in our tree so we have it for future reference.
If we're going to go down this path, why would we
Bruce Momjian wrote:
I have created a proper typedef file that I would normally use for a
pgindent run of the entire tree (it has /contrib, 2628 entries). It is
at:
http://momjian.us/expire/pgtypedefs.bsdos
Well, there are typedefs in there not used anywhere in our code, for
example
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As soon as you have a stable typedef file we can all use please update
the pgindent README to point to that URL. Keep the instructions of how
to create it in our tree so we have it for future reference.
If we're going to go down
Alvaro Herrera wrote:
Bruce Momjian wrote:
I have created a proper typedef file that I would normally use for a
pgindent run of the entire tree (it has /contrib, 2628 entries). It is
at:
http://momjian.us/expire/pgtypedefs.bsdos
Well, there are typedefs in there not used
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use neither ... My guess is that they are used in the system DLLs or
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we're going to go down this path, why would we not put the
reference typedef list into CVS?
Uh, I assume we don't want an automated system updating the file in CVS.
Nowhere did I suggest that. What I suggested is that the considered
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we're going to go down this path, why would we not put the
reference typedef list into CVS?
Uh, I assume we don't want an automated system updating the file in CVS.
Nowhere did I suggest that. What I
Alvaro Herrera [EMAIL PROTECTED] writes:
It does take a while to run though ... it's not something we'll want to
do routinely.
Well, we're not going to want to change the reference typedef list very
often anyway, because it'd just result in whitespace-thrashing in the
repository. I'm thinking
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It does take a while to run though ... it's not something we'll want to
do routinely.
Well, we're not going to want to change the reference typedef list very
often anyway, because it'd just result in whitespace-thrashing in the
Bruce Momjian [EMAIL PROTECTED] writes:
I have no problem using a URL to pull down the typedef list via wget.
How is that CVS file going to be updated?
I do not follow your thought process. You would rather depend on a URL
that has no visible commit history?
As I already noted elsewhere in
Bruce Momjian [EMAIL PROTECTED] writes:
Does someone want to look at improving the pgindent script itself?
I notice that you've carefully ignored the suggestion of re-testing
GNU indent.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have no problem using a URL to pull down the typedef list via wget.
How is that CVS file going to be updated?
I do not follow your thought process. You would rather depend on a URL
that has no visible commit history?
This does
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Does someone want to look at improving the pgindent script itself?
I notice that you've carefully ignored the suggestion of re-testing
GNU indent.
No. Why would I carefully ignore testing GNU indent? Because I am
afraid pgindent
33 matches
Mail list logo
