Hi,
Honda Shigehiro wrote:
I think this is already patched in cvs of message catalogs. Could you try
psql.po from
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgtranslation/messages/ja/psql.po
I confirmed it.
Sorry for the noise.
regards,
--
Tatsuhito Kasahara
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
I tried to run msgfmt -v ... on solaris and I got following error:
Processing file psql-cs.po...
GNU PO file found.
Generating the MO file in the GNU MO format.
Processing file psql-cs.po...
Lines 1311, 1312 (psql-cs.po): incompatible
On Monday 25 May 2009 22:02:47 Tom Lane wrote:
The issue of double translation is really a minor point; what is
bothering me is that we've got such an ad-hoc,
non-compile-time-checkable approach here. Zdenek's discovery
today that some of the format strings are flat-out wrong
On 05/25/2009 07:58 PM, Andres Freund wrote:
On 05/25/2009 07:53 PM, Andres Freund wrote:
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetterda...@fetter.org writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how
On Sunday 24 May 2009 03:37:28 Konstantin Izmailov wrote:
Number 4 is actually numeric_precision (I typed incorrectly). My
recollection is that numeric_precision sometimes expressed in radix 2 and
it caused issues for Windows apps.
It is measured in radix 2 for floating-point types and in
On Monday 25 May 2009 20:58:59 Andres Freund wrote:
and executing
`git config --global diff.context.command git-external-diff`
We already knew that you could do it with a wrapper. But that isn't the
answer we were looking for, because it will basically mean that 98% of casual
contributors
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail to
see what it buys us. I'd say that you're just reinforcing the point I
made upthread, which is that insisting that XML is the only
Peter Eisentraut wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail to
see what it buys us. I'd say that you're just reinforcing the point I
made upthread, which is that insisting
On Tue, May 26, 2009 at 8:15 AM, Peter Eisentraut pete...@gmx.net wrote:
I think we are going in the wrong direction. No one has said that they want a
machine-readable EXPLAIN format. OK, there are historically about three
people that want one, but they have already solved the problem of
On May 26, 2009, at 8:15 AM, Peter Eisentraut pete...@gmx.net wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail
to
see what it buys us. I'd say that you're just reinforcing the
Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without disturbing
the application i.e. while still returning the regular result set.
But I also like being able to conveniently run explain and get the
results
Hi,
On 05/26/2009 01:39 PM, Peter Eisentraut wrote:
On Monday 25 May 2009 20:58:59 Andres Freund wrote:
and executing
`git config --global diff.context.command git-external-diff`
We already knew that you could do it with a wrapper. But that isn't the
answer we were looking for, because it
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
snip
The problem here is (1 row) instead of (%lu row). When I run msgfmt
without -v everything works fine but I think we should fixed it (there
are more occurrences of this issue).
On May 26, 2009, at 8:46 AM, Greg Stark greg.st...@enterprisedb.com
wrote:
Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without
disturbing the application i.e. while still returning the regular
result set.
But
I'll repeat my suggestion that everyone poo-pooed: we can have the
mail list filters recognize patches, run filterdiff on them with our
prefered options, and attach the result as an additional attachment
(or link to some web directory).
I think it would be simple to do and would be happy
Peter Eisentraut pete...@gmx.net writes:
I think we are going in the wrong direction. No one has said that
they want a machine-readable EXPLAIN format. OK, there are
historically about three people that want one, but they have already
solved the problem of parsing the current format.
Well,
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
In any case, the barriers to implementing 8.3-style hash indexes in 8.4
are pretty huge: you'd need to duplicate not only the hash AM code, but
also
Peter Eisentraut pete...@gmx.net writes:
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
The problem here is (1 row) instead of (%lu row). When I run msgfmt
without -v everything works fine but I think we should fixed it (there
are more occurrences of this issue).
GNU gettext accepts
Tom Lane wrote:
Now there is a third set of desires having to do with being able to do
simple SQL-based analysis of EXPLAIN output. That's the piece I think
we don't have a good handle on. In particular, it's not clear whether
a SQL-friendly output format can be the same as either of the
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get XSLT processing into the
core XML functionality as I hope we can do this release. In fact, the
Tom Lane wrote:
That advice is, if not outright wrong, at least incredibly
short-sighted. The method breaks the instant you have any additional
values to print. For example, this ain't gonna work:
printf (ngettext (One file removed, containing %lu bytes,
Greg Stark greg.st...@enterprisedb.com writes:
I'll repeat my suggestion that everyone poo-pooed: we can have the
mail list filters recognize patches, run filterdiff on them with our
prefered options, and attach the result as an additional attachment
(or link to some web directory).
The
Isn't case I think in these two cases that using one is actively a
bad idea. These aren't English sentences they're fragments meant to
report numerical results to programmers. We don't use two or three
either.
If the value were just part of some full sentence where the actual
value
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it should use the %2$s style specifier in that case. This
should work:
printf (ngettext (One file removed, containing %2$lu bytes,
%d files removed, containing %lu bytes, n),
n, total_bytes);
How's that
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it should use the %2$s style specifier in that case. This
should work:
printf (ngettext (One file removed, containing %2$lu bytes,
%d files removed, containing %lu bytes, n),
n,
* Tom Lane t...@sss.pgh.pa.us [090526 11:20]:
Aidan Van Dyk ai...@highrise.ca writes:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken (i.e they
are such that it's impossible to actually create all the tags),
* Tom Lane t...@sss.pgh.pa.us [090526 10:56]:
Actually, configure checks to see if the local printf supports m$ or
not, and we use our own printf implementation if not. So I'm not
worried about #2. I agree with your other points though.
(So, if you wanna see how this is done, try
Peter Eisentraut wrote:
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 04:36:56PM +0200, Magnus Hagander wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
Yeah, but probably not a huge
Tom Lane wrote:
Aidan Van Dyk ai...@highrise.ca writes:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken (i.e they
are such that it's impossible to actually create all the tags), so the
git cvsimport tools
Pavel Stehule pavel.steh...@gmail.com writes:
one czech PostgreSQL user reports problem with memory - probable memleak?
Is possible to diagnose some from log?
If he's getting an actual out of memory error, let's see the memory
context map that gets dumped to the server log (or more
Aidan Van Dyk ai...@highrise.ca writes:
From the glibc printf man page:
There may be no gaps in the numbers of arguments specified using
'$'; for example, if arguments 1 and 3 are specified, argument 2 must
also be specified somewhere in the format string.
So, is skipping 1
Hello
one czech PostgreSQL user reports problem with memory - probable memleak?
Is possible to diagnose some from log?
Postgres ver. 8.3.7 .
Server 8G RAM, 32b Debian Etch.
Configuration:
shared_buffers = 324000# min 16 or max_connections*2, 8KB each
temp_buffers = 16000#
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Up to now I've always been of the opinion that fixing those tags wasn't
worth taking any risk for. But if we are thinking of moving away from
CVS, then this clearly becomes one of the hurdles we have to jump on the
way.
I think we
The link was to the memory context dump. The only suspicious context I
spotted was 300mb in MessageContext. What is lc_messages and lc_ctype
set to on this machine? Were the latest round of infinite recursion in
the character conversion routines in 8.3.7?
--
Greg
On 26 May 2009, at
I wrote:
... Notice also that we have subtly embedded the
preferred English phrase ordering here: if someone wants to pull the
same type of trick in a language where the bytecount ought to come
first, he's just plain out of luck.
Uh, scratch that [ not enough caffeine yet ]. What this coding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 11:15:21AM -0400, Aidan Van Dyk wrote:
* to...@tuxteam.de to...@tuxteam.de [090526 11:03]:
...and to put things into perspective:
to...@floh:~$ apt-cache show libxml2 libjson-glib-1.0-0 | grep ^Size
Size: 814356
Aidan Van Dyk ai...@highrise.ca writes:
Specifically, it's 2 tags, and I just remove them:
REL7_1_BETA2
REL7_1_BETA3
Previous threads:
http://news.gmane.org/find-root.php?message_id=20080220225300.ge16...@yugib.highrise.ca
On Tue, May 26, 2009 at 09:55:55AM -0400, Dave Page wrote:
from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
...and using XML introduces a dependency for those that apps that don't already
use some XML parser. I realize that since the
Greg Stark greg.st...@enterprisedb.com writes:
Were the latest round of infinite recursion in
the character conversion routines in 8.3.7?
Yes, and in any case the typical symptom of that problem was a SIGSEGV
(due to stack overrun) not an out-of-memory complaint.
Gevik Babakhani pg...@xs4all.nl writes:
I experimented with your example and noticed that pg_get_expr requires a
hack --- it insists on having a relation OID argument, because all
previous use-cases for it involved expressions that might possibly refer
to a particular table. So you have to do
On Tue, May 26, 2009 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote:
Dave Page wrote:
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get
On Tuesday 26 May 2009 17:19:50 Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it should use the %2$s style specifier in that case. This
should work:
printf (ngettext (One file removed, containing %2$lu bytes,
%d files removed, containing
Dave Page wrote:
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get XSLT processing into the
core XML functionality as I hope we can do this
* Alvaro Herrera alvhe...@commandprompt.com [090526 10:06]:
Tom Lane wrote:
That advice is, if not outright wrong, at least incredibly
short-sighted. The method breaks the instant you have any additional
values to print. For example, this ain't gonna work:
printf (ngettext
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for PostgreSQL; you
know it is coming :-)
[moving this onto -hackers, where I think it belongs]
Tom Lane wrote:
Huh? The buildfarm will only prove that HEAD of the active branches
builds. What the concern was was whether we could correctly extract
past states (particularly, but not solely, the tags corresponding to
releases) from a
Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably Java and
others) use. As a simple example, if you have a hash like { a = 1,
On Tue, May 26, 2009 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark greg.st...@enterprisedb.com writes:
I'll repeat my suggestion that everyone poo-pooed: we can have the
mail list filters recognize patches, run filterdiff on them with our
prefered options, and attach the result as
On Tuesday 26 May 2009 16:47:44 Tom Lane wrote:
The method breaks the instant you have any additional
values to print. For example, this ain't gonna work:
printf (ngettext (One file removed, containing %lu bytes,
%d files removed, containing %lu bytes, n),
Andrew Dunstan wrote:
[moving this onto -hackers, where I think it belongs]
Tom Lane wrote:
Huh? The buildfarm will only prove that HEAD of the active branches
builds. What the concern was was whether we could correctly extract
past states (particularly, but not solely, the tags
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably
Again,
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken (i.e they
are such that it's impossible to actually create all the tags), so the
git cvsimport tools that try to tags all croak on the PG CVS repository.
The
Peter Eisentraut wrote:
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for PostgreSQL;
Tom Lane wrote:
Gevik Babakhani pg...@xs4all.nl writes:
I experimented with your example and noticed that pg_get_expr requires a
hack --- it insists on having a relation OID argument, because all
previous use-cases for it involved expressions that might possibly refer
to a particular table. So
Peter Eisentraut pete...@gmx.net writes:
I tried throwing various kinds of subtle garbage into the errmsg/ngettext
line, but it was all discovered by gcc -Wall.
I experimented with this and found that indeed both format strings are
checked ... if you have a reasonably recent libintl.h AND you
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't trust filterdiff one bit :-(
For any particular reason, or just natural skepticism?
IIRC it was demonstrated to be broken the last time it was proposed
as a solution to our
* to...@tuxteam.de to...@tuxteam.de [090526 11:03]:
...and to put things into perspective:
to...@floh:~$ apt-cache show libxml2 libjson-glib-1.0-0 | grep ^Size
Size: 814356
Size: 33538
And including glib, which does all the work for libjson-glib:
Aidan Van Dyk ai...@highrise.ca writes:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken (i.e they
are such that it's impossible to actually create all the tags), so the
git cvsimport tools that try to tags all
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't trust filterdiff one bit :-(
For any particular reason, or just natural skepticism?
IIRC it was demonstrated to be broken the last time it was
Hi,
Peter Eisentraut pete...@gmx.net writes:
I was actually looking for a C library for JSON (json type for PostgreSQL;
you
know it is coming :-) ), but only found a library tied to glib, which,
considering the experience with libxml, did not excite me. If someone knows
of a different,
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
IIRC it was demonstrated to be broken the last time it was proposed
as a solution to our problems. Maybe it's been fixed since then, but
I don't have any confidence in it, since evidently it's not been stress
tested very
(sorry for top posting - stupid apple)
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
The current code is basically just gobs of text printed by different
routines all over
Uhm the rap you quoted was ambiguous but I read it as referring to the
ability I described if viewing the difference between two patches --
which I didn't name but is in fact interdiff.
--
Greg
On 26 May 2009, at 19:58, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera
Greg Stark greg.st...@enterprisedb.com writes:
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
These are implementation details ;-). Let's get a definition that
everyone can
On Tue, May 26, 2009 at 3:04 PM, Greg Stark greg.st...@enterprisedb.com wrote:
(sorry for top posting - stupid apple)
So the real elephant in the room is that the existing explain code is not
really designed to be extensible, configurable, or to be printed in
different formats.
The current
Greg Stark greg.st...@enterprisedb.com writes:
On 26 May 2009, at 19:58, Tom Lane t...@sss.pgh.pa.us wrote:
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01243.php
Uhm the rap you quoted was ambiguous but I read it as referring to the
ability I described if viewing the difference
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark greg.st...@enterprisedb.com writes:
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
These are
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
These are implementation details ;-). Let's get a definition that
everyone can sign off on, and then worry about what has to be done
to the code to make it happen.
I'm actually not
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
These are implementation details ;-). Let's get a definition that
everyone can sign off on, and then worry about
Hi, any reason not to implement an ALTER CAST statement?
the situation where i need it is for migration... i'm currently
migrating an application from sql server. and in sql server the cast
from int to bool seems like it is implicit and the application makes
use of that...now, instead of changing
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still haven't seen anything but formless handwaving as far as the SQL
table output format goes. For that matter, there's not much more than
handwaving behind the XML meme either.
Jaime Casanova jcasa...@systemguards.com.ec writes:
Hi, any reason not to implement an ALTER CAST statement?
Mainly, because we don't really *want* every thinks-he-knows-something
DBA fooling around with the built-in casts. If he actually knows enough
to know whether it's safe, then he knows
On Tue, 26 May 2009, Aidan Van Dyk wrote:
* Tom Lane t...@sss.pgh.pa.us [090526 11:20]:
Aidan Van Dyk ai...@highrise.ca writes:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken (i.e they
are such that it's
On Tue, May 26, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still haven't seen anything but formless handwaving as far as the SQL
table output format goes. For that matter,
Over a year ago we left it unresolved exactly what to do with
the now-obsolete RECHECK markings in GIST/GIN opclass definitions:
http://archives.postgresql.org/message-id/19212.1208122...@sss.pgh.pa.us
The current behavior of CVS HEAD is more or less designed to
intentionally fail in this case,
Greg Stark st...@enterprisedb.com writes:
[ point 1 here remains unresolved:
http://archives.postgresql.org/message-id/9623.1223158...@sss.pgh.pa.us ]
One possibility would be to not flatten the query but find these quals
and copy them onto the cte when planning the cte. So we would still
Sorry to come in on this discussion so late. Just catching up
Robert Haas robertmh...@gmail.com wrote:
Responding to these in bulk, I think that 1, 3, and 4 are pretty
convincing arguments that the SQL-based output format is
underspecified. I hereby promise not to do anything about
Back in January, there was some discussion of creation a web
application to make it easier to manage CommitFests.
http://archives.postgresql.org/message-id/20090127134245.ga6...@alvh.no-ip.org
This was further discussed at PGCon, and I now have a working version
for folks to play with. With the
Robert Haas robertmh...@gmail.com writes:
Back in January, there was some discussion of creation a web
application to make it easier to manage CommitFests.
This was further discussed at PGCon, and I now have a working version
for folks to play with.
Cool. Just reading your description, I
The attached addresses items#2 and 3 as listed by Bruce here:
http://momjian.us/cgi-bin/pgsql/joe
I think it is consistent with the discussions we had a PGCon last week.
Any objections to me committing this for 8.4?
On a side note, should I try to address items #1 #4 for 8.4 as well?
Hi all,
Does anyone have any tests that showcase benefits from the
posix_fadvise changes in xlog.c? I tried running some tests with dbt2
to see if any performance changes could be seen with 8.4beta2. I
thought an OLTP type test with a lot of inserts and updates would be a
good test.
On Tue, 26 May 2009, Mark Wong wrote:
Maybe there isn't enough activity to the WAL relative to the rest of the
database to show anything interesting?
Maybe you could reduce checkpoint_segments and focus on UPDATEs? That's
how I've been able to generate the most WAL activity relative to
On Tue, 26 May 2009, Robert Haas wrote:
I'm open to suggestions on how to improve this situation, though,
because it's definitely not ideal, and precludes things that reasonable
people might want to do, like contact the guy who submitted this
patch, contact the authors of all patches waiting
Hi all,
A long long time ago (in 2004) I ran a series of tests surveying the
results of changing BLCKSZ when it was used for both the WAL logs and
the rest of the database system:
http://archives.postgresql.org/pgsql-hackers/2004-03/msg01194.php
Now more than 5 years later and now being able to
Robert Haas escribió:
3. The integration with the community login system is currently rather
poor. The problem is that we can't count on patch submitters to have
a community login, and even if they do we can't count on the person
adding the patch to the system to know what it is. We could
On Tue, May 26, 2009 at 9:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
3. The integration with the community login system is currently rather
poor. The problem is that we can't count on patch submitters to have
a community login, and even if they do we can't count on the person
adding the patch
On Tue, May 26, 2009 at 10:53 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
3. The integration with the community login system is currently rather
poor. The problem is that we can't count on patch submitters to have
a community login, and even if they do we can't
2009/5/27 Tom Lane t...@sss.pgh.pa.us:
Greg Stark st...@enterprisedb.com writes:
[ point 1 here remains unresolved:
http://archives.postgresql.org/message-id/9623.1223158...@sss.pgh.pa.us ]
One possibility would be to not flatten the query but find these quals
and copy them onto the cte
Hitoshi Harada umi.tan...@gmail.com writes:
2009/5/27 Tom Lane t...@sss.pgh.pa.us:
I could still see doing what I mentioned in the prior message, which is
to flatten CTEs as if they are plain sub-selects when
1. they are non-recursive,
2. they are referenced only once, and
3. they contain
On Tue, May 26, 2009 at 10:15 PM, Greg Smith gsm...@gregsmith.com wrote:
On Tue, 26 May 2009, Robert Haas wrote:
I'm open to suggestions on how to improve this situation, though, because
it's definitely not ideal, and precludes things that reasonable people might
want to do, like contact the
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 9:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't understand why that bit would be based on community login at
all. Wouldn't contacting someone mainly need an email address?
Yes. Humor me be elaborating on your thought
Magnus Hagander a écrit :
Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
Yeah, but probably not a huge one. There is one for wx, but I don't
think it's included by
Robert Haas wrote:
I know that there are some of you reading this
who may think that we should convert to reviewboard or patchwork or
some other system. I can say that personally I'm unimpressed by those
suggestions because they will almost certainly require process changes
that this does not,
94 matches
Mail list logo
