Re: [PATCHES] drop if exists remnainder (reprise)

Andrew Dunstan wrote: Here is an updated patch for the remaining cases of DROP objtype IF EXISTS ... as recently discussed on -hackers. The cases are: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast. Regression tests and docs still to come. I

[PATCHES] small regression script improvement

This suggested patch makes sure that the regression script can actually connect to the database rather than falling through after 60 seconds, as discussed on -hackers. cheers andrew Index: pg_regress.sh === RCS file: /cvsroot/pg

Re: [PATCHES] small regression script improvement

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: This suggested patch makes sure that the regression script can actually connect to the database rather than falling through after 60 seconds, as discussed on -hackers. Oh, I see what you mean. But surely that'

Re: [PATCHES] Client build of MSVC6+ patch

Magnus Hagander wrote: What is the problem with IPV6? Did I break that with my changes to getaddrinfo.c, or is it something else? If IPv6 gets broken after all the trouble several of us went to I'll be annoyed. :-) cheers andrew ---(end of broadcast)-

Re: [PATCHES] Client build of MSVC6+ patch

Hiroshi Saito said: > Hi. > >> If IPv6 gets broken after all the trouble several of us went to I'll >> be annoyed. :-) > > Um, I think that this was the origin in problem.:-) > Why do we need to reorder the fields in the struct? cheers andrew ---(end of broadcast)---

Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)

Tom Lane said: > Jeremy Drake <[EMAIL PROTECTED]> writes: >> On Sun, 2 Jul 2006, Tom Lane wrote: >>> Nah, it was a false alarm: I was looking at the first post-patch >>> report, >>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoose&dt=2006-07-02%2003:30:01>>> but apparently mongoose had m

Re: [PATCHES] Client build of MSVC6+ patch

I'm still not very happy - we never got a reply about why the reordering was needed at all. Referring in some way to FBSD doesn't really answer for Windows. I am currently without a Windows box I can use, so I am dependent on asking questions. cheers andrew Bruce Momjian wrote: Patch ap

Re: [PATCHES] Client build of MSVC6+ patch

Petr Jelinek said: > Andrew Dunstan wrote: >> >> I'm still not very happy - we never got a reply about why the >> reordering was needed at all. Referring in some way to FBSD doesn't >> really answer for Windows. I am currently without a Windows box I can

Re: [PATCHES] Have psql display names and OUT/INOUT in \df output

David Fetter wrote: Folks, This patch makes psql's \df display functions with the names of parameters and OUT/INOUT if appropriate. Should there be a regression test for this? A doc patch? Regression tests are for server functionality, generally. Possibly docs should be patched. cheers

Re: [PATCHES] [HACKERS] 8.2 features?

Christopher Kings-Lynne wrote: The major downside is that somewhere between 9000 and 1 VALUES-targetlists produces "ERROR: stack depth limit exceeded". Perhaps for the typical use-case this is sufficient though. I'm open to better ideas, comments, objections... If the use case is peop

Re: [PATCHES] [HACKERS] 8.2 features?

Chris Browne wrote: [EMAIL PROTECTED] (Christopher Kings-Lynne) writes: The major downside is that somewhere between 9000 and 1 VALUES-targetlists produces "ERROR: stack depth limit exceeded". Perhaps for the typical use-case this is sufficient though. I'm open to better ideas, comments

Re: [HACKERS] [PATCHES] Patch for VS.Net 2005's strxfrm() bug

Hiroshi Saito wrote: > Hmm, It seems to be the bug of very unpleasant Microsoft.:D > I think that the following is desirable as an evasion measure to add. > > #if defined(_MSC_VER) && _MSC_VER == 1400 > > To be sure, it was only VS2005. > Why is this better than: #if _MSC_VER == 1400 Sur

Re: [PATCHES] [HACKERS] [COMMITTERS] pgsql: /contrib/cube improvements:

Joshua Reich wrote: Ok. Here is a diff taken from the top of the contrib tree. I have suppressed the notices in both the cube and earthdistance packages. All tests pass. Doesn't this contain parts that have been already applied? It looks to me like you need to do a cvs update (and then a s

Re: [PATCHES] [HACKERS] [COMMITTERS] pgsql: /contrib/cube improvements:

Joshua Reich wrote: You are correct. Patch against the latest HEAD attached. I have applied this and made an attempt to fix cube/expected/cube_1.out - we will still need to keep an eye on the various cube tests. cheers andrew ---(end of broadcast)-

Re: [PATCHES] [HACKERS] Possible explanation for Win32 stats regression

heh. I was just doing it the way Tom suggested - see attached. With a little more trouble we could also keep track if the listened for events and sometimes save ourselves a second call to WSAEventSelect, but I'm not sure it's worth it. cheers andrew [EMAIL PROTECTED] wrote: Is anyone wor

Re: [PATCHES] [HACKERS] Possible explanation for Win32 stats regression

[EMAIL PROTECTED] wrote: heh. I was just doing it the way Tom suggested - see attached. With a little more trouble we could also keep track if the listened for events and sometimes save ourselves a second call to WSAEventSelect, but I'm not sure it's worth it. It all depends on the overh

Re: [PATCHES] [Plperlng-devel] [EMAIL PROTECTED]: plperl enhancing return

David Fetter wrote: Folks, Pavel Stehule sent this to me, thinking I could review it. I can't just yet. It refers to Thanks in advance :) And also to me. I too am slammed. Pavel, the important thing at this stage is

Re: [PATCHES] [HACKERS] float8 regression failure (HEAD, cygwin)

Adrian Maier wrote: On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote: Reini Urban <[EMAIL PROTECTED]> writes: > BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also. You sure? INT64_IS_BUSTED should *not* be set in that case --- it's only supposed to be set if we couldn't

Re: [PATCHES] [HACKERS] float8 regression failure (HEAD, cygwin)

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: One other thought I had was that we could have pg_regress always allow a fallback to the canonical result file. Hm, that's a good thought. Want to see how painful it is to code? Would this do the trick? che

Re: [PATCHES] [HACKERS] float8 regression failure (HEAD, cygwin)

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Would this do the trick? I think Bruce changed the call convention for run_diff ... are you looking at CVS tip? Otherwise it looks reasonable. You're right. I had forgotten to do a cvs update. Fixed an

Re: [PATCHES] better support of out parameters in plperl

Pavel Stehule wrote: Hello, I send two small patches. First does conversion from perl to postgresql array in OUT parameters. Second patch allow hash form output from procedures with one OUT argument. I will try to review these in the next 2 weeks unless someone beats me to it. cheers a

Re: [PATCHES] better support of out parameters in plperl

I wrote: Pavel Stehule wrote: Hello, I send two small patches. First does conversion from perl to postgresql array in OUT parameters. Second patch allow hash form output from procedures with one OUT argument. I will try to review these in the next 2 weeks unless someone beats me to it.

Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run

Alvaro Herrera wrote: dror wrote: There were two options to solve this issue: Create a new file , grant a write permission for the Postgres user and redirect the output to that file. (EnterpriseDB use this method) Canceling the redirection at all. I choose the second option and omit the

Re: [PATCHES] [Patch] - Fix for bug #2558, InitDB failed to run

1. a patch is generated by the program "diff" 2. before we do anything, as Tom Lane says, we need verification of the problem, preferably in writing from Microsoft. cheers andrew dror wrote: 1. When saying: "Please submit the changes as patches, instead of the whole files".

Re: [HACKERS] [PATCHES] COPY view

Stefan Kaltenbrunner wrote: Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: OK, based on this feedback, I am adding COPY VIEW to the patches queue. I think we have other things that demand our attention more than a half-baked feature.

Re: [HACKERS] [PATCHES] COPY view

Hans-Juergen Schoenig wrote: Tom Lane wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: Bruce Momjian wrote: Well, the patch was submitted in time, and it is a desired feature. If we want to hold it for 8.3 due to lack of time, we can, but I don't think we can decide now that it

Re: [HACKERS] [PATCHES] COPY view

Tom Lane wrote: At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of those others. But is that what I should be spending my time on in the

Re: [HACKERS] [PATCHES] COPY view

Böszörményi Zoltán wrote: Hi, Tom Lane wrote: At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of those others. But is that what I

Re: [HACKERS] [PATCHES] COPY view

Bruce Momjian wrote: I think Alvaro is saying we need it in a few days, not longer. I thought he was saying today ;-) cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PATCHES] Adding fulldisjunctions to the contrib

Jonah H. Harris wrote: On 8/25/06, Bruce Momjian <[EMAIL PROTECTED]> wrote: Sorry, we did not get enough feedback to include this in 8.2. Please add it to pgfoundry and let's see how it goes. Yep... it's too bad. A new feature no other database has now goes to it's final resting place on p

Re: [PATCHES] Adding fulldisjunctions to the contrib

Jonah H. Harris wrote: On 8/26/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Your attitude has been lacking about this whole thing, as has a lot of other people. PgFoundry is the official sub project site for PostgreSQL. That may be the case. However, all I've seen+heard is conjecture that

Re: [PATCHES] Adding fulldisjunctions to the contrib

r Bruce Momjian - Against AgentM - Possibly For Tom Lane - Against Jonah Harris - For David Fetter - For Josh Drake - Against Andrew Dunstan - Against Josh Berkus - For Dave Page - For Well, I don't think all your 9 qualify as long time contributors, if you want to count numbers. Even if ther

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

Alvaro Herrera wrote: Böszörményi Zoltán wrote: Hi, what's the problem with COPY view TO, other than you don't like it? :-) The problem is that it required a ugly piece of code. Not supporting it means we can keep the code nice. The previous discussion led to this conclusion anyway

Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip

Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 28 July 2004 09:29 To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip Dave, now that we are nearing beta, I think we need to cor

Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip

Bruce Momjian wrote: Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I

Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip

Bruce Momjian wrote: Andrew Dunstan wrote: I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop neede

Re: [PATCHES] win32 version info

Magnus Hagander said: > > One more thing I realised - we need two different types of versioninfo > structures, because one fields tells wether it's a DLL or an app. How > would you prefer this done - either using $(WIN32VERDLL)/$(WIN32VERAPP) > (or $(PORTOBJSHLIB)/$(PORTOBJAPP) if we go down that

Re: [PATCHES] win32 version info

Magnus Hagander wrote: 2) We'll *have* to start actually bumping at least minor versions whenever we change the code in a sharaed lib. Which we don't do now, except for libpq. For example, plperl still says 0.0, and plpgsql says 1.0. Also, all the conversion procs are at 0.0, and they all build fr

Re: [PATCHES] pg_config

Peter Eisentraut wrote: Bruce Momjian wrote: Oops, sorry, done. The --pgxs option seems to have gotten lost in the conversion. It wasn't there when I did the conversion. Usual problem of duelling patches. Can you fix it, or do you need me to send in a patch? cheers andrew

Re: [PATCHES] Win32 fix for pg_dumpall

Bruce Momjian wrote: /* + * Sometime the child returns "\r\n", which doesn't match + * our version string. The backend uses + * setvbuf(stdout, NULL, _IONBF, 0), but pg_dump doesn't + * so we have to fix it here. + */ + if (strlen(line) >= 2 && + line[strlen(line)

[PATCHES] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to Windows]

UBDIR \r\nYODA\\sec_filings\\filings\\2004\\06\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\07\\*.* /SUBDIR \r\nMILLENIUM\\ExchangeBackup\\*.* /SUBDIR \r\n 2004-07-27 1 \. Thanks, Tom -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 8

Re: [PATCHES] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to Windows]

Andrew Dunstan wrote: The attached patch appears to solve the problem. However, while it makes us conform to the first sentence below from the docs, it doesn't comply with the second. Not sure what to do about that. Maybe there's a better solution? Attached patch seems much bette

Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The attached patch appears to solve the problem. However, while it makes us conform to the first sentence below from the docs, it doesn't comply with the second. Not sure what to do about that. Maybe there's a

Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to

Tom Lane said: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Should it be backported for the upcoming stable release(s)? Bruce and >> I were discussing this earlier. > > Probably a good idea, since we do support psql on Windows even in the > older releases. >

Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to

Tom Lane wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: No, I think 7.4 should do. 7.3 users will still have the dos2unix workaround available. Are you going to do the 7.4 patch, or do you need me to? I normally only keep a HEAD tree checked out. A quick look at the cvswe

Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to

Andrew Dunstan wrote: Tom Lane wrote: If you're sure the code in that routine hasn't changed since 7.4, then I can just apply the patch to that branch. It has - the prompt changes in version 1.37. But I don't think that conflict with this patch. I'll have a look this morning

Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to

Bruce Momjian wrote: One issue is that pre-8.0, psql files were opened in Win32 text mode, so we wouldn't have seen this bug on Win32, but we would on Linux. Because we open them on Win32 now in binary mode so we see control-Z it will show up on Win32 too. true, *BUT* The patch is not platfo

Re: [PATCHES] [BUGS] 8.0: Absolute path required for INITDB?

Bruce Momjian wrote: Patch to throw an error if -L is not an abolute path attached and applied. Why are we placing this restriction? What Josh tried to do seems perfectly reasonable to me. Rather I would ask why we changed the description-loading routine in version 1.7 of initdb.c to use a c

Re: [PATCHES] [BUGS] 8.0: Absolute path required for INITDB?

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Rather I would ask why we changed the description-loading routine in version 1.7 of initdb.c to use a copy from file instead of what happens everywhere else where initdb loads the file and feeds it to the postgres stdin?

Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.

Christopher Kings-Lynne wrote: At least we are guaranteed to compile against current libraries - apps outside the source tree never get that luxury and have worse compatibility problems. :) The issue is that no one has been asking for this functionality, and I can imagine it becoming quite a mess

Re: [PATCHES] pg_restore recognizing $-quotes

Bruce Momjian said: > > This is quite a large patch, but we do need a solution to this problem. > Should it be applied? > > I looked at it briefly, but felt sufficiently daunted that I gave up until I have time to review it (my time is extremely limited right now). ISTM that a very simple altern

Re: [PATCHES] pg_restore recognizing $-quotes

Tom Lane said: > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: >> ISTM that a very simple alternative would be to force pg_dump to >> inhibit dollar quoting for non-text dumps. > > I don't want to do that, but I did think that a simpler alternative > w

Re: [PATCHES] pg_restore recognizing $-quotes

Tom Lane wrote: Also, for testing purposes I think it's important that "pg_dump -Fc | pg_restore" generate exactly the same script as pg_dump. This is true currently (unless someone's broken it again recently) and I don't want to give up the property. Ok, that part I certainly buy. cheers andre

Re: [PATCHES] [HACKERS] 7.4.3 & 8.0.0beta1 + Solaris 9: default pg_hba.conf

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: At this stage of the game I would just change pg_hba.conf.sample to use '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. Yeah, that's probably the path of least resistance. Note that the comm

Re: [PATCHES] log_line_prefix additions

Ed L. wrote: Attached also is a patch to comments in sample postgresql.conf file. Subject: [PATCHES] log_line_prefix additions Date: Wednesday August 25 2004 3:26 From: "Ed L." <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] This patch against 8.0.0beta1 source adds log_line_prefix options for millisec

Re: [PATCHES] [pgsql-hackers-win32] postmaster.pid

Should we (if only for the sake of completeness) make the converse one-byte change in port/win32/signal.c? It says: void pg_queue_signal(int signum) { if (signum >= PG_SIGNAL_COUNT || signum < 0) return; ... ISTM we should not ever queue any event for signal 0. cheers andrew Dave Page w

Re: [PATCHES] log_filename_prefix --> log_filename + strftime()

Tom Lane wrote: "Ed L." <[EMAIL PROTECTED]> writes: On Friday August 27 2004 12:08, Tom Lane wrote: [ justification please ] Yes, should have said more on that item. First, I didn't see how to easily make it configurable in combination with strftime() without doing more work,

Re: [PATCHES] log_filename_prefix --> log_filename + strftime()

Tom Lane wrote: "Ed L." <[EMAIL PROTECTED]> writes: On Friday August 27 2004 12:41, Tom Lane wrote: BTW, as long as we are taking Apache as the de facto standard --- does the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or would something different be closer to the comm

Re: [PATCHES] Tsearch2 update for Win32.

Tom Lane wrote: "Magnus Hagander" <[EMAIL PROTECTED]> writes: Oh. Hmm ... wouldn't it be easier and safer to launch "psql as a subprocess? I'd say no. Executing processes from the installer environment can be a headache (we've had enough problems with initdb already..). And you have

[PATCHES] pg_hba.conf additional comment re local line

The attached tiny patch will possibly help to avoid some confusion by Windows users about the "local" line in pg_hba.conf (and thus help reduce queries to us ;-) ). It also removes an essentially content-free suffix in 2 nearby comment lines. cheers andrew Index: src/backend/libpq/pg_hba.conf.s

Re: [PATCHES] pg_hba.conf additional comment re local line

Peter Eisentraut wrote: Andrew Dunstan wrote: The attached tiny patch will possibly help to avoid some confusion by Windows users about the "local" line in pg_hba.conf (and thus help reduce queries to us ;-) ). It also removes an essentially content-free suffix in 2 nearby com

Re: [PATCHES] pg_hba.conf additional comment re local line

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The attached tiny patch will possibly help to avoid some confusion by Windows users about the "local" line in pg_hba.conf (and thus help reduce queries to us ;-) ). I was wondering if we could teach initdb to

Re: [PATCHES] pg_hba.conf additional comment re local line

The original of this seems to have gotten lost in the ether somewhere. It might turn up some day ... andrew Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The attached tiny patch will possibly help to avoid some confusion by Windows users about the "local" lin

Re: [PATCHES] [HACKERS] cvsup

Joe Conway wrote: Andrew Dunstan wrote: In postgres.cvsup: # complete distribution, including all below pgsql earthdistance I've been using this in postgres.cvsup # complete distribution, including all below repository I think Marc told me to use that at one point. Here's a small

Re: [PATCHES] plperl features

Bruce Momjian wrote: Peter Eisentraut wrote: Joshua D. Drake wrote: We expected this to a degree of course, but if we can get some of them in, it would be nice for the community who wants to use plPerl. On the other hand, it wouldn't be that nice for the community that respects a g

Re: [PATCHES] Casting INT4 to BOOL...

Sean Chittenden said: > Perl's > decision to let any non-empty string be true doesn't mean a database > should take any nonfalse-like value and assume it should be true. > 42::BOOL == TRUE, on the other hand, has a long mathematical president > wherein non-zero values are true and zero values are f

Re: [PATCHES] libpq.dll on win32

Magnus Hagander wrote: (We really oughta figure a way to generate them all from a single list file... can we rely on sed(1) being available in all Windows build environments?) Unfortunatly, no, we can't. There are sed implementations available for win32, but they're not installed by default.

Re: [PATCHES] libpq.dll on win32

Magnus Hagander wrote: The avaiable options to do it are just horrible. There is edlin, but it can't be used for anything serious. Or there is the wonderful concept of writing something in vbscript. But putting vbscript in there doesn't seem like a very good option.

Re: [PATCHES] [HACKERS] plperl Safe restrictions

David Helgason wrote: On 14. okt 2004, at 21:09, Andrew Dunstan wrote: It has just been brought to my attention that we are being very restrictive about what we allow to be done in trusted plperl. Basically we allow the :default and :base_math set of operations (run perldoc Opcode or see http

[PATCHES] new target for contrib/Makefile

If you run make installcheck in contrib it stops on the first module that fails. This is mildly annoying from the point of view of the buildfarm script, which wants to run all the available regression tests. To solve that I implemented a new target that does run them all and only fails at the e

Re: [PATCHES] new target for contrib/Makefile

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: If you run make installcheck in contrib it stops on the first module that fails. This is mildly annoying from the point of view of the buildfarm script, which wants to run all the available regression tests. Yeah. IST

Re: [PATCHES] new target for contrib/Makefile

Peter Eisentraut wrote: Tom Lane wrote: I found the following closely-related suggestion in the Make manual. It's not quite there because it doesn't seem to provide a way to pass down the current action (all/clean/install/etc) to the sub-Make. Any ideas how we could do that? I've seen the

Re: [PATCHES] plperl features

Sergej Sergeev wrote: any comments on my last patch? Speaking for myself, I am not really thinking much about new plperl stuff until we get closer to branching the code, which as I understand the current processes would be at the time we release an RC - that seems a little way off yet. cheers

Re: [PATCHES] [PATCH] 5 plperl patches

have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the b

Re: [PATCHES] FW: Win32 fix for miscinit.c

Ugh. *sigh* I wondered idly if we might be able to make a safe assumption about the staleness of the lockfile based on (possibly not very portably) comparing its mtime with the system boot time. cheers andrew Dave Page wrote: More haste, less speed... Patch attached this time! /D -Origina

Re: [PATCHES] [HACKERS] PGPASSWORD and client tools

ers andrew Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: How about an environment variable that points to a .pgpass type file. You can do that today: point $HOME at some temp directory or other. AFAIR pg_dump doesn't make any other use of $HO

Re: [PATCHES] pg_dumpall bug in PG 8.0b3 Win32 port

Luiz K. Matsumura wrote: Hi, I tried to use pg_dumpall in Win32 and receive a error message like this: pg_dump.exe: [archiver (db)] connection to database "test" failed: FATAL: user "'postgres'" does not exist Well, the word "'postgres'" is the word is between simple quotations marks and late

Re: [PATCHES] pg_dumpall bug in PG 8.0b3 Win32 port

Bruce Momjian wrote: Tom Lane wrote: "Luiz K. Matsumura" <[EMAIL PROTECTED]> writes: I modified pg_dumpall.c lines between 160 and 270 to add a #ifndef WIN32... #endif clause to pgdumpopts to store the parameters with double quotations intead simple quotation marks in case of WIN32 ports

[PATCHES] windows progname / regression fixes

Attached are 2 patches and one additional alternative contrib regression test file (for cube). The patches fix a misleading message in pg_regress.sh, and strip the .exe suffix from the result of get_progname() as previously discussed. This lets us get much further with contrib regression tests

Re: [PATCHES] [HACKERS] strange result from contrib/seg regression on windows

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Does anyone have a clue why? Evidently your sscanf isn't setting errno for overflow --- look at seg_atof() in segparse.y. This code shows several other signs of severe brain death, actually, like leaking 256 bytes on ea

[PATCHES] fix for Makefile.shlib multiply defined target

The attached patch fixes a problem with multiple target definitions that give rise to warnings like this: ../../src/Makefile.shlib:327: warning: overriding commands for target `libtsearch2.a' ../../src/Makefile.shlib:262: warning: ignoring old commands for target `libtsearch2.a' cheers andrew In

[PATCHES] fix windows contrib compile warnings for redefined macros

This patch fixes contrib so that it compiles under windows without warnings about redefines for min, max, V_UNKNOWN and IDIGNORE cheers andrew Index: intarray/_int.h === RCS file: /home/cvsmirror/pgsql/contrib/intarray/_int.h,v retri

Re: [PATCHES] fix windows contrib compile warnings for redefined

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: This patch fixes contrib so that it compiles under windows without warnings about redefines for min, max, V_UNKNOWN and IDIGNORE Surely this is wrong. You might be able to assume that Windows' definitions for min/

Re: [PATCHES] tsearch build on win32

Magnus Hagander wrote: This patch fixes the tsearch build problems reported by Andrew Dunstan. ... + ifneq (,$(findstring timezone,$(subdir))) + override CPPFLAGS+= -DBUILDING_DLL + endif That's all it took extra? Wow - easy when you know how! ;-) Thanks, Magnus. cheers a

Re: [PATCHES] initdb conf-files linebreaks

Magnus Hagander wrote: Attached patch makes initdb generate the config files with windows linebreaks when running on windows. This makes it a lot easier for the user to edit the configuration files, since any win32 plaintext editor can be used (such as notepad for example). If this is acceptable,

Re: [PATCHES] initdb conf-files linebreaks

Magnus Hagander wrote: Attached patch makes initdb generate the config files with windows linebreaks when running on windows. This makes it a lot easier for the user to edit the configuration files, since any win32 plaintext editor can be used (such as notepad for example). If this is acceptable,

Re: [PATCHES] [HACKERS] rmtree() failure on Windows

Tom Lane wrote: Try putting "RequestCheckpoint(true)" in dbcommands.c just before remove_dbtablespaces (about line 630). It looks like the bgwriter is not quite up-to-speed for this, either; you should rearrange things near line 350 of bgwriter.c so that smgrcloseall is performed before marking

[PATCHES] rmtree cleanup

The attached patch cleans up src/port/dirmod.c::rmtree() a bit. It moves the filename finding portion into its own function, and in that function only scans the directory once instead of twice. cheers andrew Index: src/port/dirmod.c ==

Re: [PATCHES] rmtree cleanup

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The attached patch cleans up src/port/dirmod.c::rmtree() a bit. It moves the filename finding portion into its own function, and in that function only scans the directory once instead of twice. Applied, along with some f

Re: [PATCHES] fix for Makefile.shlib multiply defined target

Well, one of us is confused at least. I am still seeing these warnings. cheers andrew Bruce Momjian wrote: I am told this patch is no longer required. --- Andrew Dunstan wrote: The attached patch fixes a problem with

[PATCHES] yet another .exe path fix

The "adjustments" made to my previous patch to remove a trailing .exe from get_progname()'s result broke it. The attached patch, which I have tested, fixes the breakage. cheers andrew Index: src/port/path.c === RCS file: /home/cvsmi

Re: [PATCHES] Add remove duplicate slashes to canonicalize_path()

Bruce Momjian wrote: *** 247,255 int len = strlen(path); if (len > 2 && strcmp(path + len - 2, "/.") == 0) - { trim_directory(path); - } else if (len > 3 && strcmp(path + len - 3, "/..") == 0) { trim_directory(path); As a matter of style I hate this. Stripping

[PATCHES] regression alternative for float8/openbsd

The attached alternative regression test result should fix the regression test problem seen here on OpenBSD: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emu&dt=2004-11-07%2011:35:03 cheers andrew -- -- FLOAT8 -- CREATE TABLE FLOAT8_TBL(f1 float8); INSERT INTO FLOAT8_TBL(f1) VALUES ('0.

[PATCHES] win32 cleanup

The attached patch adds a few prototypes and does a typecast, thus removing some harmless but annoying compile warnings on Win32. cheers andrew Index: src/backend/port/dynloader/win32.c === RCS file: /home/cvsmirror/pgsql/src/backend

Re: [PATCHES] [HACKERS] pg_arch.c call to sleep()

Magnus Hagander wrote: We have the following warning on Windows: pgarch.c:349: warning: implicit declaration of function `sleep' To fix it we could include the right header (which appears to be in the Windows/Mingw case), or we could replace the call by a call to pg_usleep()

[PATCHES] fix compile warning for pg_backup_tar.c

Yet another fix for a useless compile warning. This one is slightly ugly ;-( cheers andrew Index: src/bin/pg_dump/pg_backup_tar.c === RCS file: /home/cvsmirror/pgsql/src/bin/pg_dump/pg_backup_tar.c,v retrieving revision 1.45 diff -c -

Re: [PATCHES] fix compile warning for pg_backup_tar.c

Peter Eisentraut wrote: Andrew Dunstan wrote: Yet another fix for a useless compile warning. This one is slightly ugly ;-( First of all, ugly code needs to be documented in the code. Ok. Perhaps code that is expected to generate warnings should be too ;-) Then, the diff + #ifdef

Re: [PATCHES] fix compile warning for pg_backup_tar.c

Peter Eisentraut wrote: Andrew Dunstan wrote: ISTM that what is happening here is that the compiler is smart enough to know that what is in MAX_TAR_MEMBER_FILELEN can't be exceeded by any possible value of type off_t. Yeah, I think off_t is only 32 bits there. Then using INT64_IS_B

Re: [PATCHES] [HACKERS] plperl Safe restrictions

. --- Andrew Dunstan wrote: ... The patch also does some other inconsequential tidying of overlong lines, and removes some unnecessary ops in the unsafe case. These are basically cosmetic - the only significant part is replacing this: $PLContainer->permit(':base_math'

Re: [PATCHES] Win32 signals & sockets

Magnus Hagander wrote: If this is accepted I also plan to do a patch to split out the forkexec code into a separate file and try to clean up the dependencies a bit further. It'd be nice if I could get that into 8.0.0 (which would probably mean this beta, since it seems to be the last one), but it'

<    2   3   4   5   6   7   8   9   10   >