[HACKERS] IN with arrays

I'm wondering why a IN b isn't equivalent to a = ANY b for arrays, as it is for subqueries. That is, why can't you write SELECT 1 IN ( ARRAY[1, 2, 3] ); when you can write SELECT 1 = ANY ( ARRAY[1, 2, 3] ); ? I'm guessing that there is a semantic inconsistency between these expressions, as

Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4

Tom Lane wrote: "Florian G. Pflug" <[EMAIL PROTECTED]> writes: When I try to build CVS HEAD on OSX 10.4, compiling src/interfaces/ecpg/preproc/preproc.c fails with: ... If I delete pgc.c, it is rebuilt automatically, and then preproc.c compiles just fine. ... I'm using gcc 4.0.1, flex 2.5.4 and

Re: [HACKERS] RESET command seems pretty disjointed now

Tom Lane wrote: The current documentation for RESET exhibits a certain lack of, um, intellectual cohesiveness: Name RESET -- restore the value of a run-time parameter to the default value Synopsis RESET configuration_parameter RESET ALL RESET { PLANS | SESSION | TEMP | TEMPORARY } That one-

[HACKERS] SoC Students/Projects selected

All, Our seven students and projects have been officially announced by Google: http://code.google.com/soc/postgres/about.html Column-level privilege implementation for PostgreSQL by Guodong Liu, mentored by Andrew Dunstan ER diagraming tool for pgAdmin by Euler Taveira de Oliveira, mentored b

Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4

"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > When I try to build CVS HEAD on OSX 10.4, compiling > src/interfaces/ecpg/preproc/preproc.c fails with: > ... > If I delete pgc.c, it is rebuilt automatically, and then > preproc.c compiles just fine. > ... > I'm using gcc 4.0.1, flex 2.5.4 and bison

[HACKERS] Build-Problem with pgc.c on OSX 10.4

Hi When I try to build CVS HEAD on OSX 10.4, compiling src/interfaces/ecpg/preproc/preproc.c fails with: In file included from preproc.y:6951: pgc.l:3:20: error: config.h: No such file or directory In file included from pgc.l:28, from preproc.y:6951: preproc.h:996: error: conflic

[HACKERS] RESET command seems pretty disjointed now

The current documentation for RESET exhibits a certain lack of, um, intellectual cohesiveness: Name RESET -- restore the value of a run-time parameter to the default value Synopsis RESET configuration_parameter RESET ALL RESET { PLANS | SESSION | TEMP | TEMPORARY } That one-line summary has g

Re: [HACKERS] Makefile patch to make gcov work on Postgres contrib modules

Greg Stark wrote: > Perhaps the flags need to be in a separate variable instead of CFLAGS > specifically advertised to ensure the flags will show up in both > compile and linking lines. CFLAGS ordinarily does show up in both of these places. Where it doesn't, it should be added. -- Peter Eisen

Re: [HACKERS] Server-side support of all encodings

Tatsuo Ishii <[EMAIL PROTECTED]> writes: > BTW, do we have to modify pg_dump or pg_restore so that it can > automatically adjust JOHAB to UTF8 (it's the only safe encoding > compatible with JOHAB)? I'm not sure it's worth the trouble. Maybe > documenting in the release note is enough? Do we actual

Re: [HACKERS] Replacement of readline by libedit in PostgreSQL 8.1.x

Dhanaraj M wrote: Hi all, In 8.2.x version of postgres, there is a configuration switch --with-libedit-preferred prefer BSD Libedit over GNU Readline. However, I don't see this switch in 8.1.x. Since people still use 8.1.x version, is there any plan to back-port this feature? If so, I lik

[HACKERS] Replacement of readline by libedit in PostgreSQL 8.1.x

Hi all, In 8.2.x version of postgres, there is a configuration switch --with-libedit-preferred prefer BSD Libedit over GNU Readline. However, I don't see this switch in 8.1.x. Since people still use 8.1.x version, is there any plan to back-port this feature? If so, I like to work on this.

Re: [HACKERS] Wishlist updates

Lukas Kahwe Smith wrote: * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew Dunstan) * Notification payload messages (Andrew Dunstan) Unfortunately none of these got done. cheers andrew ---(end

Re: [HACKERS] Server-side support of all encodings

> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > >> I think the best way to proceed is probably to fix this in HEAD but > >> not back-patch it. During a dump and reload the encoding can be > >> corrected to something safe. > > > Ok. Shall I go ahead and remove JOHAB in HEAD? > > +1 for me. > >

[HACKERS] Wishlist updates

Hello, Currently on the wishlist [1] we have the following items as "posponed": * WITH RECURSIVE hierarchical queries (Gregory Stark) * SQL:2003 windowing queries (Gavin) * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew