On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about it
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,
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 default.
Robert Haas writes:
> On Tue, May 26, 2009 at 9:39 PM, Tom Lane 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 here?
Um, what's to elaborate? I'm t
On Tue, May 26, 2009 at 10:15 PM, Greg Smith 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 guy who submit
Hitoshi Harada writes:
> 2009/5/27 Tom Lane :
>> 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 no volatile functions.
>
2009/5/27 Tom Lane :
> Greg Stark 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 woul
On Tue, May 26, 2009 at 10:53 PM, Alvaro Herrera
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 count on the perso
On Tue, May 26, 2009 at 9:39 PM, Tom Lane 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 to the syst
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 coul
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
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 waitin
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 datab
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. Unfortunate
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?
Perh
Robert Haas 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 have one thought:
>
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
Sorry to come in on this discussion so late. Just catching up
Robert Haas 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 that
> without furth
Greg Stark 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
> materialize the re
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, and
On Tue, May 26, 2009 at 5:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 26, 2009 at 3:33 PM, Tom Lane 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 behin
On Tue, 26 May 2009, Aidan Van Dyk wrote:
* Tom Lane [090526 11:20]:
Aidan Van Dyk 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 ta
Jaime Casanova 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 enough to do it by poking the
Robert Haas writes:
> On Tue, May 26, 2009 at 3:33 PM, Tom Lane 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.
> OK, how about this:
> http:/
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
On Tue, May 26, 2009 at 3:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 26, 2009 at 3:20 PM, Tom Lane 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 happ
Robert Haas writes:
> On Tue, May 26, 2009 at 3:20 PM, Tom Lane 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 sure there's a whole lot to hash
On Tue, May 26, 2009 at 3:20 PM, Tom Lane wrote:
> Greg Stark 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 de
Greg Stark writes:
> On 26 May 2009, at 19:58, Tom Lane 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 between two patches --
> which I didn't
On Tue, May 26, 2009 at 3:04 PM, Greg Stark 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 code is basically jus
Greg Stark 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 sign off on, and then worry
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 wrote:
Alvaro Herrera writes:
Tom Lane escribió:
IIRC i
(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 t
Alvaro Herrera 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 hard.
> I think you
Hi,
Peter Eisentraut 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, small, and
Tom Lane escribió:
> Robert Haas writes:
> > On Tue, May 26, 2009 at 10:09 AM, Tom Lane 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 pr
Aidan Van Dyk 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 croak on the
* 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:
moun...@pumpkin:~/projects/postgresql/PostgreSQL$ a
Robert Haas writes:
> On Tue, May 26, 2009 at 10:09 AM, Tom Lane 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 problems. Maybe it's been fixed sinc
Peter Eisentraut 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 have
specified
Tom Lane wrote:
Gevik Babakhani 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
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 Pos
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.
Th
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan 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 Java and
>> oth
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 tag
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",
On Tue, May 26, 2009 at 10:09 AM, Tom Lane wrote:
> Greg Stark 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 t
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,
[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 c
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 :
* Alvaro Herrera [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 ("One file remov
Dave Page wrote:
> On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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, t
On Tuesday 26 May 2009 17:19:50 Tom Lane wrote:
> Alvaro Herrera 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),
On Tue, May 26, 2009 at 10:36 AM, Magnus Hagander wrote:
> Dave Page wrote:
>> On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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
>>> cor
Gevik Babakhani 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 somethi
Greg Stark 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.
regards, tom lane
--
Sent vi
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 p
Aidan Van Dyk 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
>
> http://news.gmane.org/find-root.php?message_id=2008122
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 cod
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 17:00,
Andrew Dunstan 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 need just
Pavel Stehule 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 specifically,
to stderr).
> Ser
Tom Lane wrote:
Aidan Van Dyk 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
-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
Aidan Van Dyk 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 allowed?
No --
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 Post
* Tom Lane [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 src/port/snprintf.c)
* Tom Lane [090526 11:20]:
> Aidan Van Dyk 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" t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 11:15:21AM -0400, Aidan Van Dyk wrote:
> * 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
> > Siz
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#
Tom Lane wrote:
> Alvaro Herrera 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);
>
Alvaro Herrera 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 gonna work? In the n
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
Greg Stark 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 argument that was made
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",
>
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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
> ability to leve
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 othe
Peter Eisentraut 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 this, and i
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
> Zdenek Kotala 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 all the has
Peter Eisentraut 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, obviously th
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 to
On May 26, 2009, at 8:46 AM, Greg Stark
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 also like being able to co
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
> 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 issu
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 w
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 formatted
On May 26, 2009, at 8:15 AM, Peter Eisentraut wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas 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
On Tue, May 26, 2009 at 8:15 AM, Peter Eisentraut 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 parsing the
> cu
Peter Eisentraut wrote:
> On Monday 25 May 2009 18:02:53 Tom Lane wrote:
>> Robert Haas 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 i
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
> Robert Haas 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 way to get
> > m
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 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 ra
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 Fetter 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 about
pestering git
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
> http://arch
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): incompa
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
kasahara.tatsuh...@oss.ntt.c
95 matches
Mail list logo
