Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In the spirit of incremental improvement, here is a patch that turns the
> couple of bools in PGPROC into a bitmask, and associated fallout.
Maybe declare the field as uint8 instead of char? Otherwise, +1.
> This patch also contains a change to make a
2007/10/23, Heikki Linnakangas <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> >> This doesn't work:
> >>
> >> create function exc_using(varchar) returns varchar
> >> as $$
> >> declare v varchar;
> >> begin
> >> execute 'select upper($1)' into v using ('aa');
> >
> > it cannot work. Your paramete
In the spirit of incremental improvement, here is a patch that turns the
couple of bools in PGPROC into a bitmask, and associated fallout.
This patch also contains a change to make a cancelled autovacuum
continue with the schedule (indeed to continue with the schedule on any
error), rather than ab
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Compiling contrib/uuid-ossp on my Debian laptop failed, because
> apparently on Debian the uuid.h header is installed as ossp/uuid.h.
> Attached is a patch that adds some autoconf magic to deal with that.
Applied, thanks.
BTW, src/include/pg_conf
Pavel Stehule wrote:
>> This doesn't work:
>>
>> create function exc_using(varchar) returns varchar
>> as $$
>> declare v varchar;
>> begin
>> execute 'select upper($1)' into v using ('aa');
>
> it cannot work. Your parameter is row.
Really? "execute 'select upper($1)' into v using ('aa'::var
Dave Page wrote:
> Tom Lane wrote:
>> [ looks again... ] Actually, I think you just proved my point for me.
>> The ZeroMemory call should go away, no?
>
> Yup, quite correct. v3 attached.
Great job tracking this down!
Patch looks good from here (after the fixes per Tom).
Applied, many thanks!
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> So don't initialize a local variable unless
>>> you're giving it an actually meaningful value.
>
>> The downside is that we see a useless warning that, if sufficiently
>> multiplied, might make it hard to see something
Compiling contrib/uuid-ossp on my Debian laptop failed, because
apparently on Debian the uuid.h header is installed as ossp/uuid.h.
That's probably to avoid confusion with other UUID implementations;
there's at least one included with e2fsprogs, but fortunately the header
file for that is called uu
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>>> ! /*
>>> ! * Note: We use getenv here because the more modern
>>> SHGetSpecialFolderPath()
>>> ! * will force us to link with shell32.lib which eats valuable desktop
>>> heap.
>>> ! */
>>> ! tmppath = gete
Tom Lane wrote:
> [ looks again... ] Actually, I think you just proved my point for me.
> The ZeroMemory call should go away, no?
Yup, quite correct. v3 attached.
/D
Index: src/backend/port/win32/signal.c
===
RCS file: /projects/cv
"Tom Lane" <[EMAIL PROTECTED]> writes:
>> ! /*
>> ! * Note: We use getenv here because the more modern
>> SHGetSpecialFolderPath()
>> ! * will force us to link with shell32.lib which eats valuable desktop
>> heap.
>> ! */
>> ! tmppath = getenv("APPDATA");
>
> Hmm, is there
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So don't initialize a local variable unless
>> you're giving it an actually meaningful value.
> The downside is that we see a useless warning that, if sufficiently
> multiplied, might make it hard to see something we are interested in.
[
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> [ get rid of wsprintf in favor of snprintf ]
>
> +1 for not depending on nonstandard subroutines without need.
> But please note the standard locution is snprintf(buf, sizeof(buf), ...
> Not sizeof() - 1.
Noted.
>> !char*
Dave Page <[EMAIL PROTECTED]> writes:
> [ get rid of wsprintf in favor of snprintf ]
+1 for not depending on nonstandard subroutines without need.
But please note the standard locution is snprintf(buf, sizeof(buf), ...
Not sizeof() - 1.
> ! char*tmppath=0;
Please use NULL not 0 .
A discussion on -general has been ongoing in which is was discovered
that 8.3 can exhaust the desktop heap allocated to a service with ~45
connections at which point the server will crash.
Desktop heap is allocated by user32.dll and shell32 on a per-process
basis from a 512KB pool for a non-intera
>
> This doesn't work:
>
> create function exc_using(varchar) returns varchar
> as $$
> declare v varchar;
> begin
> execute 'select upper($1)' into v using ('aa');
it cannot work. Your parameter is row. But
into v using 'aaa' doesn't work too :(
ERROR: failed to find conversion function from
Pavel Stehule wrote:
> Hello
>
> this patch add USING clause into plpgsql EXECUTE statements.
>
> Proposal:
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg00790.php
>
> I found, so dynamics statements are little bit faster with parameters,
> because we don't need call lot of in out/in
On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > I would like to present the first patch. It currently has the
> following
> > restrictions
> > a) It does not support any functional indexes.
> > b) It supports queries like select count(1) from
Gokulakannan Somasundaram wrote:
> I would like to present the first patch. It currently has the following
> restrictions
> a) It does not support any functional indexes.
> b) It supports queries like select count(1) from table where (restrictions
> from indexed columns), but it does not suppor
Hi,
I would like to present the first patch. It currently has the following
restrictions
a) It does not support any functional indexes.
b) It supports queries like select count(1) from table where (restrictions
from indexed columns), but it does not support select count(1) from table.
The Synt
20 matches
Mail list logo
