Dimitri Fontaine wrote:
If the problem is supporting 2 formats in core rather than 3, what about
replacing the current JSON support with the YAML one?
That's a step backwards. By providing JSON format, we've also satisfied
people who want YAML. Ripping out JSON would mean we *only* support
On Mon, Dec 7, 2009 at 10:20 AM, Tom Lane wrote:
> Itagaki Takahiro writes:
>> Tom Lane wrote:
>>> It was written and submitted by one person who did not bother to ask
>>> first whether anyone else thought it was worthwhile. So its presence
>>> on the CF list should not be taken as evidence tha
Magnus Hagander escribió:
> 2009/12/7 Tom Lane :
> > Magnus Hagander writes:
> >> I would also like to propose that we actually backpatch this. At least
> >> the addition of the git documentation and the update of the CVS
> >> documentation. So we get this info out there. We don't normally
> >> ba
Tom Lane writes:
> Why not? If they really want to prohibit use of a feature the upstream
> project has decided should be standard, that's their privilege.
Well, I guess they could also automate their database creation to fix
the privileges and assign the ownership of the language to the owner o
Robert Haas writes:
> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian wrote:
>> I wonder if we should rephrase this as, "How hard will this feature be
>> to add, and how hard will it be to remove in a few years if we decide we
>> don't want it?"
> Yes, I think that's the right way to think about i
On Mon, Dec 7, 2009 at 5:49 AM, Dave Page wrote:
>
> The new committers are:
>
> Robert Haas
> Simon Riggs
> Greg Stark
> ITAGAKI Takahiro
>
> Congratulations!
>
+1
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59
2009/12/7 Tom Lane :
> Magnus Hagander writes:
>> I would also like to propose that we actually backpatch this. At least
>> the addition of the git documentation and the update of the CVS
>> documentation. So we get this info out there. We don't normally
>> backpatch things like this though, so co
Robert Haas wrote:
> Bruce Momjian wrote:
>> Personally, I think AppArmor is a saner security system:
>>
>>
http://www.novell.com/linux/security/apparmor/selinux_comparison.html
> Agreed.
> I'd like to see us be able to support it. One of the things that
> I think would be worth looking i
Magnus Hagander writes:
> I would also like to propose that we actually backpatch this. At least
> the addition of the git documentation and the update of the CVS
> documentation. So we get this info out there. We don't normally
> backpatch things like this though, so comments on that?
The sort o
Tom Lane wrote:
> Euler Taveira de Oliveira writes:
> > While testing the EXPLAIN BUFFERS patch I found a bug. I'm too tired to
> > provide a fix right now but if someone can take it I will appreciate. It
> > seems
> > ExplainJSONLineEnding() doesn't expect es->grouping_stack list as a null
> >
Xin Wang writes:
> I have added a catalog table with an index on a non-unique column. I
> want to cache this non-unique index like other unique indexes in
> syscache. Is there any way to cache a non-unique index?
No, not with syscache.
regards, tom lane
--
Sent via pgsq
Greg Smith wrote:
> After getting off to a good start, it looks like this patch is now
> stuck waiting for a second review pass from Kevin right now, with
> no open items for Andres to correct. Since the only issues on the
> table seem to be that of code aesthetics and long-term planning
> for
Itagaki Takahiro writes:
> Tom Lane wrote:
>> It was written and submitted by one person who did not bother to ask
>> first whether anyone else thought it was worthwhile. So its presence
>> on the CF list should not be taken as evidence that there's consensus
>> for it.
> Should we have "Needs
On Mon, Dec 07, 2009 at 09:53:32AM +0100, Albe Laurenz wrote:
> abindra wrote:
> > Next quarter I am planning to do an Independent Study course
> > where the main objective would be to allow me to get familiar
> > with the internals of Postgres by working on a project(s). I
> > would like to wor
On Mon, Dec 07, 2009 at 04:08:28PM +0100, Magnus Hagander wrote:
> 2009/11/26 Tom Lane :
> > Magnus Hagander writes:
> >> I assume you are fine with the addition of some info about git, but
> >> what about the removal of those two chapters suggested?
> >
> > I agree that we needn't try to cover ma
On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > This is no harder than many of the other seemingly crazy things I have
>> > done, e.g. Win32 port, client library threading. ?If this is a feature
>> > we should have, I will get it done or get others to help me complet
2009/11/26 Tom Lane :
> Magnus Hagander writes:
>> I assume you are fine with the addition of some info about git, but
>> what about the removal of those two chapters suggested?
>
> I agree that we needn't try to cover material that's in the CVS manual.
> As somebody mentioned upthread, a sentence
On Mon, Dec 07, 2009 at 10:49:13AM +, Dave Page wrote:
> On behalf of the core team, I'm pleased to announce that the
> PostgreSQL Project has expanded it's team of "committers", those
> people who are able to make direct changes to the PostgreSQL source
> code respository. As the project is ex
Dimitri Fontaine writes:
> So should the decision to remove plpgsql be on the hosting platform
> hands or the hosted database owner?
Why not? If they really want to prohibit use of a feature the upstream
project has decided should be standard, that's their privilege.
The argument against seems t
On Mon, Dec 7, 2009 at 6:49 AM, Dave Page wrote:
> On behalf of the core team, I'm pleased to announce that the
> PostgreSQL Project has expanded it's team of "committers", those
> people who are able to make direct changes to the PostgreSQL source
> code respository. As the project is extremely c
On Mon, 2009-12-07 at 19:26 +0900, Fujii Masao wrote:
> On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote:
> > If you really think that changing the file is a possibility between
> > processes reading them, then I would just take a full temp copy of the
> > file, read it in postmaster, read it in
Robert Haas wrote:
> > This is no harder than many of the other seemingly crazy things I have
> > done, e.g. Win32 port, client library threading. ?If this is a feature
> > we should have, I will get it done or get others to help me complete the
> > task.
>
> Well, I have always thought that it wo
Tom Lane wrote:
The only thing that I'd be comfortable with is
copying the snap and modifying the copy.
I don't see an easy way to do that with the current code; CopySnapshot()
is static and PushUpdatedSnapshot() seems to be a bit of a pain since it
messes up some of the existing code which u
Hello,
I’m a student from Nankai University in China. Now I and my team do a
project which aims to integrate XML to Postgresql. What I do is to complete
the function of XML Update.
Now I’m researching in concurrency control. I have read the code about the
concurrency control for a long time an
also there is integer overflow:
postgres=# select levenshtein('','',1,10,1);
levenshtein
-
-1179869184
(1 row)
should we reject arguments greater than,say, 1 ?
maximum input length is 255 currently, so the maximum numbers involved
would be about 1*255
On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro
wrote:
>> (ii) format: why does text output format have less counters than the other
>> ones?
>
> That's because lines will be too long for text format. I think the
> three values in it are the most important and useful ones.
I disagree. I object
Hi,
I have added a catalog table with an index on a non-unique column. I
want to cache this non-unique index like other unique indexes in
syscache. Is there any way to cache a non-unique index? I just want the
index to reside in the memory to speed up the index lookup. Thank you!
Wang
--
Sent
The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider:
leki_dev=# select levenshtein('','a',2,4,5);
levenshtein
-
1
(1 row)
leki_dev=# select levenshtein('a','',2,4,5);
levenshtein
-
1
(1 row)
leki_dev=# select levenshtein
2009/12/4 Tsutomu Yamada :
> Thanks to suggestion.
> I send pathces again by another mailer for the archive.
>
> Sorry to waste resources, below is same content that I send before.
Just in case anybody was wondering, I've added myself as a reviewer of
this one for next commitfest - I doubt that's
* Dimitri Fontaine:
> Well we have JSON and agreed it was a good idea to have it. Now JSON is
> a subset of YAML and some would prefer another YAML style (me included).
YAML is rather difficult to parse, and most parsers assume a trusted
document source because they support arbitrary class instan
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Tallying up the votes on this patch
First, I would hope that you don't overlook the author of the patch (me)
as an "aye" vote. :) Additionally, if you are going t
Tom Lane writes:
> Right, just like every other thing that's pre-installed. If a
> particular installation wishes to let individual DB owners control this,
> the superuser can drop plpgsql from template1. It's not apparent to me
> why we need to allow non-superusers to override the project's dec
On Monday 07 December 2009 02:12:43 Greg Smith wrote:
> After getting off to a good start, it looks like this patch is now stuck
> waiting for a second review pass from Kevin right now, with no open
> items for Andres to correct. Since the only issues on the table seem to
> be that of code aesthet
In response to Dave Page :
> On behalf of the core team, I'm pleased to announce that the
> PostgreSQL Project has expanded it's team of "committers", those
> people who are able to make direct changes to the PostgreSQL source
> code respository. As the project is extremely conservative about any
>
On behalf of the core team, I'm pleased to announce that the
PostgreSQL Project has expanded it's team of "committers", those
people who are able to make direct changes to the PostgreSQL source
code respository. As the project is extremely conservative about any
changes made to the source code to m
On mån, 2009-12-07 at 17:14 +0900, Hitoshi Harada wrote:
> 2009/12/7 Itagaki Takahiro :
> >
> > Tom Lane wrote:
> >
> >> It was written and submitted by one person who did not bother to ask
> >> first whether anyone else thought it was worthwhile. So its presence
> >> on the CF list should not be
On Mon, Dec 7, 2009 at 5:28 PM, Simon Riggs wrote:
> If you really think that changing the file is a possibility between
> processes reading them, then I would just take a full temp copy of the
> file, read it in postmaster, read it in startup, then delete temp file.
This seems more robust becaus
2009/12/7 Greg Smith :
> Itagaki Takahiro wrote:
>
> Greg Smith wrote:
>
>
>
> I'm thinking that I should rename this new function
> to pg_stat_reset_bgwriter so it's obvious how limited its target is.
>
>
> I don't think it is a good name because we might have another cluster-level
> statictics n
Hi,
Greg Smith writes:
> Robert Haas wrote:
>> The main point here for me is that the JSON format is already
>> parseable by YAML parsers, and can probably be turned into YAML using
>> a very short Perl script - possibly even using a sed script. I think
>> that it's overkill to support two forma
Simon Riggs wrote:
> On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote:
>> Reading the file separately in each process would cause trouble with
>> PGC_POSTMASTER params. All backends must agree on their values.
>
> Looking at the parameters in recovery.conf I don't believe they would
> c
abindra wrote:
> Next quarter I am planning to do an Independent Study course
> where the main objective would be to allow me to get familiar
> with the internals of Postgres by working on a project(s). I
> would like to work on something that could possibly be
> accepted as a patch.
>
> This
On Mon, 2009-12-07 at 10:02 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
> >
> >> For what it's worth, this doesn't seem particularly unlikely or
> >> unusual to me.
> >
> > I don't know many people who shutdown both nodes of a hi
On Mon, 2009-12-07 at 10:13 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > What postgresql.conf already does is read file separately in each
> > process, so no data passing.
>
> No it doesn't. Postmaster reads the file once, and backends inherit the
> values at fork(). In EXEC_BACKEND c
2009/12/7 Itagaki Takahiro :
>
> Tom Lane wrote:
>
>> It was written and submitted by one person who did not bother to ask
>> first whether anyone else thought it was worthwhile. So its presence
>> on the CF list should not be taken as evidence that there's consensus
>> for it.
>
> Should we have
Simon Riggs wrote:
> What postgresql.conf already does is read file separately in each
> process, so no data passing.
No it doesn't. Postmaster reads the file once, and backends inherit the
values at fork(). In EXEC_BACKEND case, postmaster writes all the
non-default values to a separate file, whi
Simon Riggs wrote:
> On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
>
>> For what it's worth, this doesn't seem particularly unlikely or
>> unusual to me.
>
> I don't know many people who shutdown both nodes of a highly available
> application at the same time. If they did, I wouldn't expe
On Mon, 2009-12-07 at 13:03 +0900, Fujii Masao wrote:
> On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs wrote:
> > Proposal is to split out the couple of lines in
> > readRecoveryCommandFile() that set important state and make it read in
> > an option block that can be used by caller. It would then be
101 - 147 of 147 matches
Mail list logo
