[PATCHES] contrib/ltree Readme operator name

2004-01-25 Thread Kris Jurka
contrib/ltree's readme has => instead of >= as the operator name for greater than or equal to. Kris Jurka Index: contrib/ltree/README.ltree === RCS file: /projects/cvsroot/pgsql-server/contrib/ltree/README.ltree,v retrieving revisio

Re: [PATCHES] appendStringInfoString() micro-opt

2004-01-25 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > This patch replaces a bunch of call sites of appendStringInfo() with > appendStringInfoString(). I doubt this saves enough cycles to be worth doing, but if it floats your boat ... When I'm tempted to make a dubious micro-optimization, I always ask myself

[PATCHES] Win32 signals patch

2004-01-25 Thread Magnus Hagander
Here's the latest win32 signals code, this time in the form of a patch against the latest shapshot. It also includes the replacement of kill() with pqkill() and sigsetmask() with pqsigsetmask(). Passes all tests fine on my linux machine once applied. Still doesn't link completely on Win32 - there

Re: [PATCHES] next draft of list rewrite

2004-01-25 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > I've attached the latest header and implementation files (pg_list.h > and list.c, respectively) for the new linked list implementation. I'm > pretty satisfied with the new API: now would be the ideal time to > suggest any changes you think I should make to

Re: [PATCHES] ANALYZE patch for review

2004-01-25 Thread Tom Lane
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > Here is a first attempt at a patch to allow a customised ANALYZE > function to be specified for user-defined types, relating to the > following two threads: > http://archives.postgresql.org/pgsql-hackers/2003-10/msg00113.php and > http://archives.pos

Re: [PATCHES] next draft of list rewrite

2004-01-25 Thread Neil Conway
Tom Lane <[EMAIL PROTECTED]> writes: > I thought the plan was to keep the API exactly the same as before, > with the single exception of having to use ListCell* rather than > List* as the type of pointers used to iterate through a list. I thought that once we had decided to change the API, anythin

Re: [PATCHES] appendStringInfoString() micro-opt

2004-01-25 Thread Neil Conway
Tom Lane <[EMAIL PROTECTED]> writes: > I'm not objecting to your doing it, exactly, just suggesting that > there are better things to spend your time on. Heh, probably true :-) I'll put this on the back-burner for now, and repost a complete patch later if I get around to it. > This I would objec

[update] Re: [PATCHES] Patch to bring \copy syntax more in line with SQL copy

2004-01-25 Thread Bill Moran
Please find a pair of updated patches attached. The first is against src/bin/pgsql/copy.c It changes the acceptable syntax for \copy to allow the following: [ [with|using] delimiter[s] [as] delimiter ] Improvements over the previously posted patch: 1) c++ style comments removed. 2) Comments with

Re: [PATCHES] next draft of list rewrite

2004-01-25 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > I thought that once we had decided to change the API, anything was > fair game: either we need to change every call site of the API (which > would be required if we adopted ListCell* as the type of the foreach > iteration variable), or we don't. Changing t

[PATCHES] Clarify libpq docs

2004-01-25 Thread Gavin Sherry
The attached patch clarifies (or, rather, makes explicit) to readers how to handle memory management for char pointers returned by libpq functions. Although the sections on PQfinish(), PQclear() and PQfreemem() give an indication that all pointers returned by functions point to memory allocated in