[PATCHES] ToDo: Allow PL/pgSQL EXECUTE query_var INTO record_var;

2005-06-26 Thread Pavel Stehule
Done Regards Pavel Stehule ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Euler Taveira de Oliveira
Hi Petr, One more thing, do you have more concerns about that max connection out of the fact it uses pgstat ? For example are guc variables ok for this or should it be new variable in pg_shadow pg_database etc - I would like to rewrite it just once or twice not ten times. IIRC,

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Petr Jelínek
Euler Taveira de Oliveira wrote: IIRC, people want the last one. We have more control if we can set it per user or per database. Like I said, guc variables _can_ be set per user or per database if you use right context. Talking about pgstat, I think you can rely on it 'cause it can be

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Alvaro Herrera
On Sun, Jun 26, 2005 at 07:46:32PM +0200, Petr Jelínek wrote: Euler Taveira de Oliveira wrote: IIRC, people want the last one. We have more control if we can set it per user or per database. Like I said, guc variables _can_ be set per user or per database if you use right context. I

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Petr Jelínek
Alvaro Herrera wrote: I don't think this approach is very user-friendly. I'd vote for the catalog approach, I think. Ok I am fine with both but catalog changes would mean more hacking of ALTER DATABASE and ALTER USER. Maybe you could make some checks against the shared array of PGPROCs

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Heikki Linnakangas
On Sun, 26 Jun 2005, Petr Jelínek wrote: Alvaro Herrera wrote: Maybe you could make some checks against the shared array of PGPROCs (procarray.c), for the per-database limit at least. Not sure about per-user limit. Thats good idea (I could maybe add userid to PGPROC struct too) but I think

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Alvaro Herrera
On Sun, Jun 26, 2005 at 08:52:55PM +0200, Petr Jelínek wrote: Alvaro Herrera wrote: Maybe you could make some checks against the shared array of PGPROCs (procarray.c), for the per-database limit at least. Not sure about per-user limit. Thats good idea (I could maybe add userid to PGPROC

Re: [PATCHES] [HACKERS] language handlers in public schema?

2005-06-26 Thread Andrew Dunstan
Andrew Dunstan wrote: Why --- what else is needed beyond the addition of those clauses to the one query? There are tests for both the function and the handler based on finfo-dobj.namespace-dump that inhibit output if we're in the catalog schema. If we go down this path ISTM the

Re: [PATCHES] Function's LEAST, GREATEST (with ignore NULL)

2005-06-26 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: I sending correction. Variant B respect Oracle behavior. Applied with minor editing. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL

[PATCHES] BUG #1467: fe_connect doesn't handle EINTR right

2005-06-26 Thread AgentM
Attached is a patch which corrects the behavior. I verified that the patch does not interfere with normal operation (using psql) but unfortunately the code path is virtually impossible to test without a really slow connection to a postgresql server [which I thankfully don't have]. To test

Re: [PATCHES] BUG #1467: fe_connect doesn't handle EINTR right

2005-06-26 Thread Tom Lane
AgentM [EMAIL PROTECTED] writes: Attached is a patch which corrects the behavior. I verified that the patch does not interfere with normal operation (using psql) but unfortunately the code path is virtually impossible to test without a really slow connection to a postgresql server [which

Re: [PATCHES] BUG #1467: fe_connect doesn't handle EINTR right

2005-06-26 Thread Andrew Dunstan
AgentM said: Attached is a patch which corrects the behavior. I verified that the patch does not interfere with normal operation (using psql) but unfortunately the code path is virtually impossible to test without a really slow connection to a postgresql server [which I thankfully don't

Re: [PATCHES] Escape patch applied

2005-06-26 Thread Bruce Momjian
Got it. I couldn't find any more. --- Andrew Dunstan wrote: Bruce Momjian wrote: I have applied the E'' escape patch to CVS head. You missed one regression fix: int8-exp-three-digits.out:

Re: [PATCHES] COPY FROM performance improvements

2005-06-26 Thread Bruce Momjian
Please change 'if(' to 'if (', and remove parenthese like this: for(start = s; (*s != c) (s (start + len)) ; s++) My only other comment is, Yow, that is a massive patch. --- Luke Lonergan wrote: Tom, Is it

Re: [PATCHES] Removing Kerberos 4

2005-06-26 Thread Neil Conway
Magnus Hagander wrote: This patch removes Kerberos version 4 support from the backend and libpq. Applied, thanks. Bruce, can you mark the Remove krb4 TODO item as finished? Thanks. -Neil ---(end of broadcast)--- TIP 6: Have you searched our

Re: [PATCHES] COPY FROM performance improvements

2005-06-26 Thread Bruce Momjian
Luke Lonergan wrote: Attached has spaces between if,for, and foreach and (, e.g., if( is now if (. It definitely looks better to me :-) Massive patch - agreed. Less bloated than it was yesterday though. Good, thanks. What about the Protocol version 2? Looks like it could be added back

Re: [PATCHES] COPY FROM performance improvements

2005-06-26 Thread Bruce Momjian
Luke Lonergan wrote: Bruce, Well, there has been no discussion about removing version 2 support, so it seems it is required. This should do it - see attached. Those parentheses are still there: for (start = s; (*s != c) (s (start + len)) ; s++) It should be: for (start

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Petr Jelínek
Alvaro Herrera wrote: Prepared transactions can be filtered out by checking the pid struct member. I'm not sure if anybody would object to adding the authenticated user Id to ProcArray, but I don't see why not. Very well, it seems to work this way (although the code for storing userid in

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Neil Conway
Petr Jelínek wrote: I am bit confused now because I am no really sure if it's intended to be this way or not - 8.0 behaviour was to report numbackends when stats were on, now it reports numbackends when stats_row_level is true. Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD

Re: [PATCHES] COPY FROM performance improvements

2005-06-26 Thread Alvaro Herrera
On Sun, Jun 26, 2005 at 09:17:14PM -0700, Luke Lonergan wrote: Bruce, Those parentheses are still there: for (start = s; (*s != c) (s (start + len)) ; s++) It should be: for (start = s; *s != c s start + len; s++) Thanks - didn't understand what you'd meant

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD later today barring any objections. I looked at this but did not actually see the code path that requires forcing creation of the per-DB entry right at this spot. The HASH_FIND calls for this

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Neil Conway
Tom Lane wrote: I looked at this but did not actually see the code path that requires forcing creation of the per-DB entry right at this spot. The HASH_FIND calls for this hashtable seem to all happen on the backend side not the collector side. Can you explain why we need this? Yeah, I

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Tom Lane wrote: I looked at this but did not actually see the code path that requires forcing creation of the per-DB entry right at this spot. The HASH_FIND calls for this hashtable seem to all happen on the backend side not the collector side. Can you