Re: [HACKERS] Request for supported platforms

://home.akademie.de/~IBarwick/IRIX_65_regression.diffs Otherwise no apparent problems and the server started fine. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Please help

you have a problem with semaphores? See: http://www.ca.postgresql.org/docs/faq-english.html#3.4 (A lack of available semaphores can also produce the message No space left on device.) Sorry I can't help any further. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] No bison and NAMEDATALEN 31: initdb failure?

On Tuesday 30 July 2002 00:23, Tom Lane wrote: Ian Barwick [EMAIL PROTECTED] writes: - Does src/include/postgres_ext.h count as a parser definition file? No, it doesn't. Your experience sounds like you may have neglected to do a full rebuild after altering NAMEDATALEN. (By default, we

[HACKERS] No bison and NAMEDATALEN 31: initdb failure?

for, so I'm not sure if this is intended behaviour. Questions: - Does src/include/postgres_ext.h count as a parser definition file? - If not shouldn't the above warning include something like And don't even think about changing NAMEDATALEN? Apologies if I've missed something obvious. Ian Barwick

[HACKERS] Q: unexpected result from SRF in SQL

(1); bar --- 139059784 (1 row) What is this number? It often varies from query to query. Possibly an error-in-disguise because of something to do with the calling context? Just curious ;-) Ian Barwick ---(end of broadcast)--- TIP

Re: [HACKERS] Q: unexpected result from SRF in SQL

why I posted the question is that I had defined a function that should have worked, but kept giving me back strange numbers, so I spent a whole five minutes trying to debug the function before I realised I was calling it in the wrong way (doh). An error here would be a Good Idea, IMHO. Ian Barwick

Re: [HACKERS] Schemas: status report, call for developers

On Wednesday 01 May 2002 06:38, Tom Lane wrote: Ian Barwick [EMAIL PROTECTED] writes: How can I restrict the query to the schemas in the current search path, i.e. the schema names returned by SELECT current_schemas() ? Well, this is the issue open for public discussion. We could define

Re: [HACKERS] Set Returning Functions (SRF) - request for patch review

See contrib/dblink. The version in cvs HEAD has two that return sets -- dblink() which returns an int, and dblink_get_pkey() which returns text. Thanks, now I can see what I was doing wrong Yours Ian Barwick ---(end of broadcast)--- TIP 4

Re: [HACKERS] Set Returning Functions (SRF) - request for patch review and comment

On Monday 06 May 2002 18:51, Joe Conway wrote: (...) Request for help: - So far I've tested with SQL and C functions. (...) Can you post an example of a function in C? (I'm trying out your patch from Friday). Thanks, Ian Barwick ---(end

Re: [HACKERS] Schemas: status report, call for developers

++--+ foo| bar| r| foo2 | bar| r| (2 rows) i.e. user joe can see which objects exist in schema foo2, even though he has no USAGE privilege. (Is this behaviour intended?) Yours Ian Barwick ---(end of broadcast

Re: [HACKERS] Schemas: status report, call for developers

a critical look at anything I do. Yours Ian Barwick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] psql and output from \?

ready? Patch attached (diff against CVS, replacing previous patch). Ian Barwick Index: help.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/help.c,v retrieving revision 1.48 diff -c -r1.48 help.c *** help.c 2002/03/11 18:26:20

<    1   2