Re: [PATCHES] Patch for adding DATACUBE operator

2003-06-30 Thread Andrew Dunstan
I'm curious to know why you implement this as a union of queries, since, unless my understanding is badly awry, you have all the information necessary for the ALL rows by running the base (ie. without cube) query, Why not just run that query and then add the ALL rows from examining the results?

[PATCHES] nitpick consistency patch for pg_dump.c

2003-07-18 Thread Andrew Dunstan
This is a totally trivial patch for something that was a very minor nit that annoyed me the other day while I was documenting my current project. It makes pg_dump use the same layout for types as for tables, by putting \n\t before the first field and \n before the final ); Can't really justify

Re: [PATCHES] nitpick consistency patch for pg_dump.c

2003-07-18 Thread Andrew Dunstan
trivial or not the patch was broken. *sigh*. it's been a long day. This patch will work. sorry andrew RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dump.c,v retrieving revision 1.335 diff -c -w -r1.335 pg_dump.c *** pg_dump.c 25 Jun 2003 04:08:19 - 1.335 --- pg_dump.c

Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]

2003-07-25 Thread Andrew Dunstan
Finally I understand the issue, I think. But wouldn't an ordinary user on SCO wanting to install a private copy of Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME? If so, that seems to me to mandate that this not be in the vanilla distribution. OS Vendors commonly make

[PATCHES] cidr docco

2003-08-08 Thread Andrew Dunstan
I just noticed that the sample pg_hba.conf in the docs doesn't contain any use of CIDR masks - here's a patch that adds a couple of sample lines and associated comments. Sorry for the lateness - I should have done this a month ago. cheers andrew Index: client-auth.sgml

[PATCHES] logging enhancements, minor code cleanup

2003-08-09 Thread Andrew Dunstan
The attached patch does 3 things: . logs connection ends if log_connections = true . provides a new option log_line_format which allows addition of extra information on a log line before the keyword. Currently supported are user name and database name, but it is easily extensible. The string is

[PATCHES] doc patch - linux memory handling

2003-08-22 Thread Andrew Dunstan
As discussed on Hackers. enjoy andrew Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.200 diff -c -w -r1.200 runtime.sgml *** doc/src/sgml/runtime.sgml

Re: [PATCHES] doc patch - linux memory handling

2003-08-22 Thread Andrew Dunstan
only concern was that the docs would give people info that would make things worse rather than better, and nobody else was doing anything about it. cheers andrew Neil Conway wrote: Minor SGML gripes... On Fri, Aug 22, 2003 at 10:00:00AM -0400, Andrew Dunstan wrote: ! To avoid

Re: [PATCHES] doc patch - linux memory handling

2003-08-22 Thread Andrew Dunstan
It appears we are back in the you need a non-empty password mode. Anyway, here's the revised patch. andrew Andrew Dunstan wrote: I didn't find a single instance of a warning tag in the doc sources. I did find a warning in an unadorned para, in func.sgml. Anyway, I made the changes (using

[PATCHES] allow any ip4 or ip6 loopback address to match in default pg_hba.conf

2003-09-03 Thread Andrew Dunstan
Here's a patch that does what has been discussed on Hackers to allow a default setting in pg_hba.conf for loopback addresses, and should cause no problems no matter what style of ipv6 is or isn't configured. If it's wanted I'll document it, if not I won't :-) BTW, I notice that the sample

Re: [PATCHES] fix log_min_duration_statement logic error

2003-09-22 Thread Andrew Dunstan
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: I also don't particularly like the format of the log message (for one thing, the duration_statement prefix in the log message shouldn't include an underscore, it's not a variable or anything -- and the case can be made that if we printed

[PATCHES] pg_id.c windows fix

2003-10-04 Thread Andrew Dunstan
Here's a patch for pg_id.c that lets it compile cleanly and run on Windows. cheers andrew Index: src/bin/pg_id/pg_id.c===RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_id/pg_id.c,vretrieving revision 1.22.2.1diff -c -w

Re: [PATCHES] pg_id.c windows fix

2003-10-05 Thread Andrew Dunstan
PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: PG Patches [EMAIL PROTECTED] Sent: Sunday, October 05, 2003 12:17 AM Subject: Re: [PATCHES] pg_id.c windows fix Can you tell me what Win32 compile environment can't handle a sizeof() as a function parameter? ! GetUserName(pw-pw_name, sizeof(pw

Re: [PATCHES] fix log_min_duration_statement logic error

2003-10-05 Thread Andrew Dunstan
Bruce Momjian wrote: Btw., I was wondering, are we kidding ourselves when we display microsecond precision to the user? What accuracy do these measurements have in respect to what they are actually supposed to measure? Not sure. I think the microsecond stuff is accurate to some

[PATCHES] fix for strict-alias warnings

2003-10-11 Thread Andrew Dunstan
This patch will stop gcc from issuing warnings about type-punned objects when -fstrict-aliasing is turned on, as it is in the latest gcc when you use -O2 enjoy andrew strict-alias.patch Description: Binary data ---(end of broadcast)---

Re: [PATCHES] fix for strict-alias warnings

2003-10-11 Thread Andrew Dunstan
to contemplate that. cheers andrew - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: Andrew Dunstan [EMAIL PROTECTED]; PG Patches [EMAIL PROTECTED] Sent: Saturday, October 11, 2003 1:29 PM Subject: Re: [PATCHES] fix for strict-alias warnings Bruce

Re: [PATCHES] fix for strict-alias warnings

2003-10-12 Thread Andrew Dunstan
a pain. andrew - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: PG Patches [EMAIL PROTECTED] Sent: Sunday, October 12, 2003 7:18 PM Subject: Re: [PATCHES] fix for strict-alias warnings Andrew Dunstan wrote: - Original Message

Re: [PATCHES] fix for strict-alias warnings

2003-10-12 Thread Andrew Dunstan
- Original Message - From: Tom Lane [EMAIL PROTECTED] Bruce Momjian [EMAIL PROTECTED] writes: I have attached and applied the following patch to use makeNode for structures that will later be cast to Node*, rather than having them be allocated as stack variables. AFAICT, this

Re: [PATCHES] fix for strict-alias warnings

2003-10-14 Thread Andrew Dunstan
Tom Lane wrote: BTW, I haven't looked at the problem spots in detail. How many of them are due to the use of MemSet in conjunction with other access to a chunk of memory? ISTM that we need not worry about code motion around a MemSet call, since that would require the compiler to prove that the

Re: [PATCHES] fix for strict-alias warnings

2003-10-14 Thread Andrew Dunstan
Andrew Dunstan wrote: there were 3 calls to MemSet it complained about - all in src/backend/storage/lmgr/proc.c, and all zeroing out the timeval structure. (is MemSet actually a gain in this instance?) And looking at it even closer, 2 of the 3 cases of calling MemSet appear

Re: [PATCHES] fix for strict-alias warnings

2003-10-14 Thread Andrew Dunstan
Peter Eisentraut wrote: Andrew Dunstan writes: And looking at it even closer, 2 of the 3 cases of calling MemSet appear to be unnecessary, as the zeroed out values are immediately overwritten. We need to zero out the holes in the structures so that hash functions work correctly. I

Re: [PATCHES] fix for strict-alias warnings

2003-10-14 Thread Andrew Dunstan
Manfred Spraul wrote: I've asked the question on the gcc devel list. The first reply was that MemSet violates strict aliasing rules: http://gcc.gnu.org/ml/gcc/2003-10/msg00524.html I think we must either add -fno-strict-aliasing, or switch to the c compiler memset functions for gcc. The

Re: [PATCHES] fix for strict-alias warnings

2003-10-14 Thread Andrew Dunstan
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, what gcc versions support -fno-strict-aliasing? Do we need a configure test for it? Perhaps ... although it is recognized in 2.95.3 and probably for a good ways before that. It looks to me like what has changed in gcc 3.3 is not

Re: [PATCHES] fix for strict-alias warnings

2003-10-15 Thread Andrew Dunstan
Spraul [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] Cc: Andrew Dunstan [EMAIL PROTECTED]; Patches (PostgreSQL) [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 5:01 PM Subject: Re: [PATCHES] fix for strict-alias warnings Tom Lane wrote: Manfred Spraul [EMAIL PROTECTED] writes: After

Re: [PATCHES] [HACKERS] random_fract and aix compiler bug

2003-10-17 Thread Andrew Dunstan
Tom Lane wrote: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: ! } while (!(z 0 z MAX_RANDOM_VALUE)); ! } while (z == 0 || z == MAX_RANDOM_VALUE); This seems fairly ugly, since it eliminates the original coding's positive guarantee that the final result is in 0 x 1. Does your

[PATCHES] make check improvement for cygwin

2003-10-27 Thread Andrew Dunstan
The attached patch limits parallelism for "make check" on cygwin to 10 - meaning that at least on my installation "make check" actually succeeds at last. cheers andrew pg_regress.patch Description: Binary data ---(end of broadcast)--- TIP

Re: [PATCHES] make check improvement for cygwin

2003-10-27 Thread Andrew Dunstan
- Original Message - From: Tom Lane [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: PG Patches [EMAIL PROTECTED] Sent: Monday, October 27, 2003 7:41 PM Subject: Re: [PATCHES] make check improvement for cygwin Andrew Dunstan [EMAIL PROTECTED] writes: The attached patch

Re: [PATCHES] make check improvement for cygwin

2003-10-28 Thread Andrew Dunstan
- Original Message - From: Tom Lane [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: PG Patches [EMAIL PROTECTED] Sent: Monday, October 27, 2003 11:12 PM Subject: Re: [PATCHES] make check improvement for cygwin Andrew Dunstan [EMAIL PROTECTED] writes: Something like

Re: [PATCHES] make check improvement for cygwin

2003-10-29 Thread Andrew Dunstan
Message - From: Jason Tishler [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: PG Patches [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 8:40 AM Subject: Re: [PATCHES] make check improvement for cygwin Andrew, Something like this? make MAX_CONNECTIONS=10 check AFAICT

Re: [PATCHES] make check improvement for cygwin

2003-10-29 Thread Andrew Dunstan
Jason Tishler wrote: Andrew, On Wed, Oct 29, 2003 at 08:45:30AM -0500, Andrew Dunstan wrote: The number isn't hardcoded at all Understood. (except for the warning on gygwin if you choose some high value) The above is my concern -- sorry, for being unclear. I don't want to issue

Re: [PATCHES] make check improvement for cygwin

2003-11-02 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Well, I posted the note last night but I finished the patch today, because it was very simple and took so little time. I've committed this with the later revision about the warning message, and some other minor cleanups. I added

Re: [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: It passes all the regression tests. I have also included a diff against Andrew's version so you can see my changes. It seems Andrew had a very current version of initdb. The only update he missed was the change to test the number of

Re: [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: It passes all the regression tests. I have also included a diff against Andrew's version so you can see my changes. It seems Andrew had a very current version of initdb. The only update he missed was the change to test the number of connections before shared buffers ---

Re: [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: Here is a slightly modified version of Andrew's great work in making a C version of initdb. Other than minor cleanups, the only big change was to remove rmdir handling because we using rm -r and rmdir /s in commands/dbcommands.c, so we might as use the same thing for

Re: [pgsql-hackers-win32] [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: Yes, I was concerned too that everything was in there. I checked the initdb.sh logs and found that the only thing not added was the checking of the max number of connections before checking the max number of buffers, which I added. The other stuff was in there. I also

Re: [PATCHES] [pgsql-hackers-win32] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: My comments: I have no problem with shelling out to rmdir - although my goal was to avoid shelling out to anything other than postgres itself. I think recreating the datadir if we didn't create it initially should be OK in that case

Re: [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Consider also the strong likelihood that the data directory's parent directory is owned by root, Again, this directory recreate happens only on Win32, an I thought it would be OK there. Windows has no concept of directory

Re: [PATCHES] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: Also, I see this at the top of the code: * author: Andrew Dunstan mailto:[EMAIL PROTECTED] * * Copyright (C) 2003 Andrew Dunstan * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions

Re: [PATCHES] [pgsql-hackers-win32] initdb in C

2003-11-08 Thread Andrew Dunstan
Bruce Momjian wrote: I ran some tests using XP CMD and found: C:\test and \test works but: test does not work. Since I see that the output always has a leading path, On Windows, pgpath is guaranteed to be a full path (see call to expanded_path() ) exactly so it works

Re: [PATCHES] [pgsql-hackers-win32] initdb in C

2003-11-12 Thread Andrew Dunstan
Apologies. Here's the patch. There may be other very minor differences in wording, too. But if that's all I missed I won't think I did too badly :-) cheers andrew Tom Lane wrote: What's become of initdb's initial note about who you are? $ initdb The files belonging to this database system

Re: [PATCHES] [pgsql-hackers-win32] initdb in C

2003-11-12 Thread Andrew Dunstan
OK, this works. cheers andrew Andrew Dunstan wrote: ARRGGHH! It has a typo!. new patch shortly. Andrew Dunstan wrote: Apologies. Here's the patch. There may be other very minor differences in wording, too. But if that's all I missed I won't think I did too badly :-) cheers andrew Tom

Re: [PATCHES] [pgsql-hackers-win32] initdb in C

2003-11-13 Thread Andrew Dunstan
Note to self: stop working when brain is clearly malfunctioning. *This* patch works. Please disregard previous. thanks andrew Andrew Dunstan wrote: OK, this works. cheers andrew Andrew Dunstan wrote: ARRGGHH! It has a typo!. new patch shortly. Andrew Dunstan wrote: ? initdb Index

Re: [PATCHES] [HACKERS] heads up -- subtle change of behavior of new initdb

2003-11-14 Thread Andrew Dunstan
darnit! patch attached. (Thinks - do we need to worry about suid sgid and sticky bits on data dir?) andrew Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I just noticed tonight that the new initdb introduced a subtle change of behavior. I use a shell script to automate the process

Re: [PATCHES] [HACKERS] heads up -- subtle change of behavior of

2003-11-14 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: darnit! patch attached. Applied with correction (you got the return-value check backwards) and further work to deal reasonably with error conditions occurring in check_data_dir. darnit again. I'm taking a break - my head

Re: [PATCHES] improve overcommit docs

2003-11-16 Thread Andrew Dunstan
That covers it extremely well. cheers andrew Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: At the time I wrote the original 2.6 was not out even in prerelease, which is why I was deliberately somewhat vague about it. It is still in prerelease, and it will in fact work slightly

Re: [PATCHES] SRA Win32 sync() code

2003-11-16 Thread Andrew Dunstan
Manfred Spraul wrote: Tom Lane wrote: Seriously though, if we can move the bulk of the writing work into background processes then I don't believe that there will be any significant penalty for regular backends. And I believe that it would be a huge advantage from a correctness point of view

Re: [PATCHES] initdb copyright notice

2003-11-17 Thread Andrew Dunstan
Rod Taylor wrote: On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote: Neil Conway asked me if we need a copyright notice to cover the code I borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here is a patch to include it. Unless I'm mistaken, all of the FreeBSD code

Re: [PATCHES] initdb copyright notice

2003-11-17 Thread Andrew Dunstan
Bruce Momjian wrote: I have grabbed code from NetBSD before, and I just mention that fact at the top of the file. There is no need to repeat their license as it is the same as our license. I just added the last line: * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group *

Re: [PATCHES] initdb copyright notice

2003-11-17 Thread Andrew Dunstan
Neil Conway wrote: To summarize, my understanding is that there are two problems: (1) Some of the files in the main source tree are 4 clause BSD. Since PostgreSQL is derived from these files, we fall under its licensing restrictions, namely the advertising clause. I

Re: [PATCHES] internationalization of initdb

2003-11-19 Thread Andrew Dunstan
heh. Now I can cross that off my todo list :-) Euler Taveira de Oliveira wrote: Hi, I just enable support for internationalization of initdb. I used the same style from scripts. The files need to be put in initdb directory (nls.mk and po/pt_BR.po). The patch was made under CVS HEAD.

Re: [PATCHES] [BUGS] (Modified) Patch request for PostgreSQL 7.4

2003-12-09 Thread Andrew Dunstan
It just struck me that *maybe* a portable solution would be to put the awk output inside genbki.sh in a .h file and then #include it in a one line .c file which is passed to the preprocessor. Would that keep the (strange) HP compiler happy? cheers andrew ViSolve Open Source Team wrote: **

[PATCHES] distinguish between all and all in pg_hba.conf

2003-12-19 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The minimal disturbance change might be to teach the parser to distinguish between a quoted 'all' and an unquoted 'all', and forget the '*' idea. Probably we ought to go with that, on backwards-compatibility grounds. OK

Re: [PATCHES] psql \i handling ~ in specified file name

2003-12-21 Thread Andrew Dunstan
Zach Irmen said: Tom Lane [EMAIL PROTECTED] writes: What happens if getenv(HOME) returns NULL? Yeah, the strdup fails. I'll take it out to fix that. You also need to think about Windows Can I just ifndef WIN32 and not think about it? I'm not sure how that would work either. If we are

[PATCHES] pg_usleep

2003-12-30 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I wrote: There are a couple of other places where [select()] is used for small sleeps (storage/lmgr/s_lock.c and access/transam/xact.c) - What is the preferred way to handle these 2 cases? We could handle them

Re: [PATCHES] pg_usleep

2003-12-31 Thread Andrew Dunstan
Claudio Natoli said: patch + new file attached. Haven't tested on Windows, but should be fine. Would be, except for a small typo (conditional operator has an additional : instead of a ?). Darnit. please fix when applying. Also, we might want to change to SleepEx, depending on how we

Re: [PATCHES] [patch] 7.4 initdb - drop trailing slash from $PGDATA

2004-01-19 Thread Andrew Dunstan
Tom Lane said: Peter Eisentraut [EMAIL PROTECTED] writes: Jari Aalto wrote: I made a mistake while running 7.4 under W2k/Cygwin, so perhaps the patch would give user a little more comfort. I don't see how. Please explain. CVS-tip initdb seems to be written to suppress any trailing slash

Re: [PATCHES] reading uninitialized buffer

2004-02-01 Thread Andrew Dunstan
This time it is my fault, rather than freebsd's ;-) I think I can do something slightly cleaner than this, though, by hoisting the buf termination above the test. We could also replace the strncmp calls with strcmp calls if the buffer has its nul. I will post something soon. cheers andrew

Re: [PATCHES] reading uninitialized buffer

2004-02-01 Thread Andrew Dunstan
... and here it is. As for the test being outside the if statement, it is true that that might waste a few cycles, but it hardly matters. Personally, I would prefer to replace the if statement with this: if (c == EOF || c == '\n') { *buf = '\0'; return; } and then it

Re: [PATCHES] reading uninitialized buffer

2004-02-01 Thread Andrew Dunstan
OK, then *This* patch does it the way I think is clearest. Most of it is just reindenting. cheers andrew Dennis Bjorklund wrote: On Sun, 1 Feb 2004, Andrew Dunstan wrote: As for the test being outside the if statement, it is true that that might waste a few cycles, but it hardly matters

Re: [PATCHES] reading uninitialized buffer

2004-02-02 Thread Andrew Dunstan
Neil Conway wrote: Andrew Dunstan [EMAIL PROTECTED] writes: OK, then *This* patch does it the way I think is clearest. Most of it is just reindenting. Okay, I applied this patch, and made a few additional cleanups along the way (the whole function and a couple other things don't need

[PATCHES] log session end - again

2004-02-02 Thread Andrew Dunstan
This patch brings up to date what I did last year (now unfortunately bitrotted) to allow the logging of the end of a session, enabled by the config setting log_session_end - true. It produces lines like these: for a local connection: [21340] LOG: session end: duration: 0:00:23.41 user=andrew

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Andrew Dunstan
Stephan Szabo wrote: On Mon, 2 Feb 2004, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: I don't know of a memcpy() implementation that would actually bail out if called with two equal pointers, but perhaps there is one in existence somewhere. This isn't a bug, and I see

Re: [PATCHES] win32 inode fix

2004-02-09 Thread Andrew Dunstan
Bruce Momjian wrote: Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: In reading the patch, it seems he is only doing zero equals unknown on Win32, so I think we are fine. That's what I was trying to avoid: where possible, we shouldn't introduce platform-dependent

Re: [PATCHES] [HACKERS] dollar quoting

2004-02-08 Thread Andrew Dunstan
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: After staring at the code for a long time, I think I see how to do this. It's complicated a bit by the fact that $ is a valid identifier character. So my current thinking is to say that if we see

Re: [PATCHES] [HACKERS] dollar quoting

2004-02-09 Thread Andrew Dunstan
Tom Lane wrote: A bigger problem here: + else if (!dol_quote line[i] == '$' + !isdigit(line[i + thislen]) + (dol_end = strchr(line+i+1,'$')) != NULL + (i == 0 || + ! ((line[i-1] 0x80) !=

Re: [PATCHES] [HACKERS] dollar quoting

2004-02-09 Thread Andrew Dunstan
just puts that function in mainloop.c, but perhaps it belongs elsewhere (string_utils.c maybe?). I don't have strong opinions on that. Enjoy andrew Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Comments welcome. Reviewers: I am not sure I got multi-byte stuff right in psql

Re: [PATCHES] [HACKERS] dollar quoting

2004-02-14 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I ended up not using a regex, which seemed to be a little heavy handed, but just writing a small custom recognition function, that should (and I think does) mimic the pattern recognition for these tokens used by the backend lexer

Re: [PATCHES] [HACKERS] dollar quoting

2004-02-15 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: ... But how about 42$foo$ This is a syntax error in 7.4, and we propose to redefine it as an integer literal '42' followed by a dollar-quote start symbol. The test should not succeed anywhere

[PATCHES] log_line_info

2004-02-23 Thread Andrew Dunstan
Attached is a patch for tagging log lines produced by backends. It is not quite ready for application - this is for people to look over and play with. For my testing I used the following settings: log_connections = true log_disconnections = true log_line_info = '%T [%P] [EMAIL

[PATCHES] dollar quoting with flex

2004-02-24 Thread Andrew Dunstan
(Fourth try ;-) Attached is a patch for dollar quoting in the backend and in psql (with the new flex scanner). I'm fairly confident about the backend (because this is mainly Tom's work adapted :-) ) but rather less so about psql - I don't entirely understand all the odd states in psql's

[PATCHES] dollar quoting for plpgsql

2004-02-25 Thread Andrew Dunstan
Tom Lane wrote: I think plpgsql's lexer also needs to be taught about dollar-quoting. The attached patch appears to do the trick: floobl=# create or replace function testme() returns text language plpgsql as $$ floobl$# begin return $foo$a'\b$bar$foo$; end; floobl$# $$; CREATE

Re: [PATCHES] log_line_info

2004-02-28 Thread Andrew Dunstan
Bruce Momjian wrote: +case 'C': + j += snprintf(result+j,result_len-j,%lx.%lx, +(long)(MyProcPort-session_start.tv_sec), +(long)MyProcPid); One other comment. Are you sure you want a

Re: [PATCHES] log_line_info

2004-02-28 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Attached is a patch for tagging log lines produced by backends. It is not quite ready for application - this is for people to look over and play with. For my testing I used the following settings: log_connections = true log_disconnections = true

Re: [PATCHES] log_line_info

2004-02-29 Thread Andrew Dunstan
Peter Eisentraut wrote: Andrew Dunstan wrote: Attached is a patch for tagging log lines produced by backends. It is not quite ready for application - this is for people to look over and play with. For my testing I used the following settings: log_connections = true log_disconnections = true

Re: [PATCHES] log_line_info

2004-02-29 Thread Andrew Dunstan
Peter Eisentraut wrote: Andrew Dunstan wrote: I will do docs. We could sensibly get rid of log_pid and log_timestamp with my latest patch. I would also suggest getting rid of log_source_port, since there really isn't any reason *not* to log the source port. There is the very definite

[PATCHES] Docs slightly broken

2004-02-29 Thread Andrew Dunstan
There appears to be a missing row closing tag in funcs.sgml, which made make html complain loudly for me. Fix below. cheers andrew Index: func.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving

[PATCHES] log_line_info

2004-02-29 Thread Andrew Dunstan
I think this is now ready for application, unless someone objects. Since the last patch I posted, I have done the following: . changed the escapes to lower case, as Peter prefers. This is also in line with what Apache does, which is the nearest equivalent I can think of. . added 2 new escapes:

Re: [PATCHES] log_line_info

2004-03-01 Thread Andrew Dunstan
Jon Jensen wrote: On Sun, 29 Feb 2004, Andrew Dunstan wrote: . changed source port reporting from host:port to host(port) to avoid IP6 address ambiguity. I have no idea how widespread this is, but recent versions of BIND write it this way: 127.0.0.1#953 ::1#953 Personally I'd kind

[PATCHES] defer statement logging until after parse

2004-03-11 Thread Andrew Dunstan
The attached patch is for review, not application. It defers logging statements until after they have been parsed. There should be no observable difference in behaviour if there is a successful parse, and on error the following traces appear: line:3 ERROR: syntax error at or near se3d2 at

Re: [PATCHES] defer statement logging until after parse

2004-03-12 Thread Andrew Dunstan
Tom Lane wrote: The current definition of log_statement has no problem because we print the whole string, once, before parsing starts. If you put a printout into the per-parse-tree loop then I think you are going to get multiple printouts of the same string. I didn't intend to - I intended to

Re: [PATCHES] [pgsql-hackers-win32] initdb problen

2004-03-12 Thread Andrew Dunstan
I believe that the attached patch may solve this setlocale() problem, but I do not have a Windows box handy on which to test it. Can somebody who does please try and let us know the results? thanks andrew Andrew Dunstan wrote: the answer is very probably here: http

Re: [PATCHES] defer statement logging until after parse

2004-03-12 Thread Andrew Dunstan
Bruce Momjian wrote: Well, if that is the question, then I don't want to reorder the query printout from the error. OK. I'll let someone else do it. I have no need for it. Forget I spoke. cheers andrew ---(end of broadcast)--- TIP 8: explain

[PATCHES] default psql to localhost on platforms without unix domain sockets

2004-03-15 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Also, what is the default connection mode of psql? It should probably be equivalent to -h localhost, shouldn't it? Now that is something I had not thought of. Seems we can assume a Win32 psql can never use unix domain sockets, so defaulting

Re: [PATCHES] [HACKERS] compile warning in CVS HEAD

2004-03-18 Thread Andrew Dunstan
Patch attached. Also adds a malloc() check that Neil wanted. cheers andrew Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: *sigh* my local (linux) man for gettimeofday says this: struct timeval { time_t tv_sec;/* seconds

Re: [PATCHES] [HACKERS] compile warning in CVS HEAD

2004-03-18 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Patch attached. Also adds a malloc() check that Neil wanted. Er, what on God's green earth is elog.c doing malloc'ing stuff at all? This should be a palloc in the ErrorContext; that's what it's for. As is, this code is guaranteed

Re: [PATCHES] listening addresses

2004-03-22 Thread Andrew Dunstan
Tom Lane wrote: Please revise, and update the docs too. Second attempt attached. The fatal message now reads no configured listening socket available, but I am not wedded to the wording. I also was not sure how to mark up * in the docs. cheers andrew Index: doc/src/sgml/runtime.sgml

Re: [PATCHES] Initial eventlog support on win32

2004-03-22 Thread Andrew Dunstan
Magnus Hagander wrote: This patch adds initial eventlog support on win32. It's good enough for most purposes, but we will probably want a specific message DLL later to format the messages nicer. I'm extremely happy to see this being done - it's a must-have for WIN32, I think. The patch mimcs

[PATCHES] dollar quoting and pg_dump

2004-03-23 Thread Andrew Dunstan
Here's my attempt, as discussed earlier today. As always, comments welcome. I did provide (and use) a fallback mechanism after all, for the case of a function with a non-empty probin. A few examples from a dump of the regression db: -- -- Name: tg_hub_adjustslots(character, integer,

Re: [PATCHES] dollar quoting and pg_dump

2004-03-23 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Here's my attempt, as discussed earlier today. As always, comments welcome. I did provide (and use) a fallback mechanism after all, for the case of a function with a non-empty probin. Applied with light

Re: [PATCHES] listening addresses

2004-03-24 Thread Andrew Dunstan
Bruce Momjian said: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Second attempt attached. The fatal message now reads no configured listening socket available, but I am not wedded to the wording. I also was not sure how to mark up * in the docs. I went with no socket

Re: [PATCHES] installdir patch for win32

2004-03-25 Thread Andrew Dunstan
Tom Lane wrote: Claudio Natoli [EMAIL PROTECTED] writes: Supplement to previous win32 patch for dfmgr. Win32 replacement for configure time constants like PKGLIBDIR. This is exactly the sort of cruft I was hoping we would not get saddled with by a Windows port. If the problem is that we

Re: [PATCHES] hint infrastructure setup (v3)

2004-04-02 Thread Andrew Dunstan
Fabien COELHO wrote: The last time I studied this stuff (which was quite a while back) the follow set was something an LR parser generator would have to compute anyway. Yes. I don't know whether bison's internal tables expose that set in any useful fashion, but it surely seems worth a

Re: [PATCHES] [HACKERS] Function to kill backend

2004-04-03 Thread Andrew Dunstan
Magnus Hagander wrote: I think any such facility is inherently a security risk, since it means that a remote attacker who's managed to break into your superuser account can randomly zap other backends. Now admittedly there's plenty of other mischief he can do with superuser privs,

Re: [PATCHES] hint infrastructure setup (v3)

2004-04-05 Thread Andrew Dunstan
Tom Lane wrote: Fabien COELHO [EMAIL PROTECTED] writes: (b) write a new recursive descendant parser, and drop gram.y er, that's recursive descent :-) Been there, done that, not impressed with the idea. There's a reason why people invented parser generators... Well, unless you are a

Re: [PATCHES] [HACKERS] logging statement levels

2004-04-06 Thread Andrew Dunstan
Unless I'm missing something, this patch has the effect that with values of ddl or mod for log_statement, a statement with a parse error will not be logged, which was what I hoped to avoid. cheers andrew Bruce Momjian wrote: Andrew Dunstan wrote: Here are some options: 1. change

Re: [PATCHES] [HACKERS] logging statement levels

2004-04-06 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Unless I'm missing something, this patch has the effect that with values of ddl or mod for log_statement, a statement with a parse error will not be logged, which was what I hoped to avoid. Right. The query type can't be determined during

Re: [PATCHES] [HACKERS] logging statement levels

2004-04-06 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: Andrew Dunstan wrote: Unless I'm missing something, this patch has the effect that with values of ddl or mod for log_statement, a statement with a parse error will not be logged, which was what I hoped to avoid

Re: [PATCHES] [HACKERS] logging statement levels

2004-04-06 Thread Andrew Dunstan
Bruce Momjian wrote: Right now we have log_min_error_statement: #log_min_error_statement = panic # Values in order of increasing severity: # debug5, debug4, debug3, debug2, debug1, # info,

Re: [PATCHES] [HACKERS] logging statement levels

2004-04-06 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: Right now we have log_min_error_statement: #log_min_error_statement = panic # Values in order of increasing severity: # debug5, debug4, debug3, debug2, debug1

[PATCHES] COPY for CSVs

2004-04-08 Thread Andrew Dunstan
Attached is an undocumented patch that implements COPY for CSVs according to the scheme recently discussed. I believe it handles all the straightforward and perverse cases that were discussed (including multiline fields and partially quoted fields). I have done some light testing on it, but

  1   2   3   4   5   6   7   8   9   >