Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
This appears to be due to this on mingw:
/mingw/include
Peter,
Thanks! Great to have you participating!
> I suppose I'll try out my 8.4 app, which uses dblink and hstore, on
> 9.0 alpha5 and see if anything breaks, and play around with the
> features that are new to 9.0, as outlined on the postgres wiki for the
> "SFPUG Beta Test Day". This seems a l
Michael Tharp writes:
> Due to popular demand on #postgresql (by which I mean David Fetter), I
> have been spending a little time making the internal SQL parser
> available to clients via a C-language SQL function. The function itself
> is extremely simple: just a wrapper around a call to raw_p
Most Esteemed Hackers:
Due to popular demand on #postgresql (by which I mean David Fetter), I
have been spending a little time making the internal SQL parser
available to clients via a C-language SQL function. The function itself
is extremely simple: just a wrapper around a call to raw_parser
On Apr 2, 2010, at 12:34 PM, Kevin Grittner
wrote:
> Josh Berkus wrote:
>
>> Robert,
>
>> do you think you could put up replacement tarballs today?
>
> If you don't hear from him soon, perhaps he's traveling:
>
> http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php
Yeah, sorry, I'm
Alexey Klyukin writes:
> Is there a reason why only a table free SQL functions are allowed to
> be inlined ? I wonder why a simple SQL function containing only a
> SELECT * FROM table can't be expanded inline ?
If you're thinking of just replacing the call with a sub-SELECT
construct, that's no
Hello,
I'd like to put myself forward to test Dave's alpha5 windows binaries
tomorrow. I use that platform for about 75% of my pg work, and others
tend to have limited enthusiasm for it (as I guess I would if I had
the luxury of being able to), so that seems to be where I would be of
most use. I s
Hi,
Is there a reason why only a table free SQL functions are allowed to be inlined
? I wonder why a simple SQL function containing only a SELECT * FROM table
can't be expanded inline ? Is there an interest in expanding the class of SQL
functions that can be inlined ?
Thanks,
--
Alexey Klyu
Josh Berkus wrote:
> Robert,
> do you think you could put up replacement tarballs today?
If you don't hear from him soon, perhaps he's traveling:
http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Robert,
> I'm obviously very sorry for the hassle and frustration caused by this
> mistake, especially to Dave Page, but hopefully you understand that I
> was trying rather hard to get this right; and perhaps the Wiki page
> can also be improved to mention some of these details.
Bound to happen t
Tatsuhito Kasahara writes:
> pgstattuple (and pgstatindex) does not contain CHECK_FOR_INTERRUPTS().
> Therefore, we can not stop pgstattuple() by using the signal while a
> large table is processed.
> Here is the patch to solve it.
Seems to be a good idea --- will apply. Thanks!
Magnus Hagander writes:
> On Fri, Apr 2, 2010 at 17:26, Tom Lane wrote:
>> I disapprove of the whole approach, actually. The right way to fix this
>> is to not touch or replace libpq at all, but to change walreceiver to
>> use libpq's async-query facilities directly. Instead of PQexec, use
>> P
On Fri, Apr 2, 2010 at 17:26, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
>>> Sorry for the delay. The attached patch replaces PQexec() used by dblink
>>> and libpqwalreceiver with pgwin32_PQexec() which is the win32 version of
>>> PQexec().
>>>
On Apr 1, 2010, at 9:34 PM, Petr Jelinek wrote:
>> I ended up reinventing the wheel and writing another JSON library:
>>
>> http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
>>
>> This is a first release, and it doesn't really have a name besides
>> "json". It's very similar to c
Magnus Hagander writes:
> On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
>> Sorry for the delay. The attached patch replaces PQexec() used by dblink
>> and libpqwalreceiver with pgwin32_PQexec() which is the win32 version of
>> PQexec().
>>
>> pgwin32_PQexec() is provided as the library 'libp
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Fri, 2010-04-02 at 10:46 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > 1. DROP OWNED BY does not drop databases owned by the role. Should it? I
> > would say not. This causes this strangeness
>
> > postgres=# drop owned by fred;
> > DROP OWNED
> > postgres=# drop user fred;
> > ERROR: role
Tom Lane wrote:
Anyway, I hadn't looked at your patch before, but now that I have, it's
not even approximately what I was suggesting. What I thought you should
do was change ruleutils.c to print the parameter expressions at the call
site, ie in the T_SubPlan and T_AlternativeSubPlan cases in get
Takahiro Itagaki writes:
> Can we take the patch for 9.0? The bug is registered as an open item:
> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
Given that there are still problems with it, applying the patch for 9.0
would mean changing the behavior of xmlconcat in 9.0 and then again
Simon Riggs writes:
> 1. DROP OWNED BY does not drop databases owned by the role. Should it? I
> would say not. This causes this strangeness
> postgres=# drop owned by fred;
> DROP OWNED
> postgres=# drop user fred;
> ERROR: role "fred" cannot be dropped because some objects depend on it
> DETAI
Few minor things...
1. DROP OWNED BY does not drop databases owned by the role. Should it? I
would say not. This causes this strangeness
postgres=# drop owned by fred;
DROP OWNED
postgres=# drop user fred;
ERROR: role "fred" cannot be dropped because some objects depend on it
DETAIL: access to
On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
> On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao wrote:
>>> Just replacing PQexec() with PQsendQuery() is pretty straightforward, we
>>> could put that replacement in a file in port/win32. Replacing
>>> PQconnectdb() is more complicated because you
Hi,
I use Ubuntu 9.04 (GCC 4.3.3).
Build was failed too.
I was able to compile with some small correction.
All are the one that relates only to the return value of write() and fgets().
(1) src/backend/utils/error/elog.c
elog.c: In function 'write_console':
elog.c:1698: error: ignoring return v
On fre, 2010-04-02 at 06:42 -0400, Robert Haas wrote:
> Forgive me for being a little annoyed here, but I actually did follow
> that document quite closely. Unfortunately it omits to mention a few
> key points.
Sorry, I had suspected that you didn't do a clean cvs export. It was a
frequent proble
Hi,
pgstattuple (and pgstatindex) does not contain CHECK_FOR_INTERRUPTS().
Therefore, we can not stop pgstattuple() by using the signal while a
large table is processed.
Here is the patch to solve it.
Best regards,
--
NTT OSS Center
Tatsuhito Kasahara
diff -cr pgsql/contrib/pgstattuple/pgstatt
On Apr 2, 2010, at 5:18 AM, Peter Eisentraut wrote:
> On fre, 2010-04-02 at 04:48 -0400, Robert Haas wrote:
>> I can't easily get on line to check this just now, but did I
>> accidentally bundle my Makefile.custom into this tarball?
>
> Uhum, if you had followed
> http://wiki.postgresql.org/wiki/A
On Fri, 2010-04-02 at 04:51 -0400, Robert Haas wrote:
> On Apr 1, 2010, at 7:06 PM, Simon Riggs wrote:
> > On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
> >> I discovered tonight that if you shut down a server, create
> >> recovery.conf with standby_mode = 'on', and start it back up again,
On Fri, Apr 2, 2010 at 9:48 AM, Robert Haas wrote:.
>
> I can't easily get on line to check this just now, but did I
> accidentally bundle my Makefile.custom into this tarball?
D'oh! That explains the pain I had building the binaries (mainly the
add-ons). We assumed that -Werror was an intentiona
On tor, 2010-04-01 at 23:28 -0700, Josh Berkus wrote:
> Fails on:
> Ubuntu, gcc 4.3.3
> Ubuntu, gcc 4.4.1
> OSX 10.5, gcc 4.0.1*
Ubuntu builds with hardening options by default, which cause several
warnings.
Not sure about the OSX issue.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On fre, 2010-04-02 at 04:48 -0400, Robert Haas wrote:
> I can't easily get on line to check this just now, but did I
> accidentally bundle my Makefile.custom into this tarball?
Uhum, if you had followed
http://wiki.postgresql.org/wiki/Alpha_release_process then this couldn't
have happened.
--
On Apr 1, 2010, at 7:06 PM, Simon Riggs wrote:
> On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
>> I discovered tonight that if you shut down a server, create
>> recovery.conf with standby_mode = 'on', and start it back up again,
>> you get this:
>>
>> LOG: database system was shut down at
On Apr 2, 2010, at 2:28 AM, Josh Berkus wrote:
> Tom, Robert, etc.
>
> Ok, this issue seems to be specific to some versions of gcc. Note
> that
> in testing this nobody enabled any special compile or environment
> variables of any kind, so if there's a -Werror where it shouldn't be,
> it's in our
Josh Berkus wrote:
> Ok, this issue seems to be specific to some versions of gcc. Note that
> in testing this nobody enabled any special compile or environment
> variables of any kind, so if there's a -Werror where it shouldn't be,
> it's in our code.
Hi, cygwin also has -Werror in default, an
33 matches
Mail list logo
