On Fri, Nov 13, 2009 at 02:47:56AM +, Greg Stark wrote:
> On Fri, Nov 13, 2009 at 2:35 AM, daveg wrote:
> > I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is
> > expected
> > to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
>
> What would this mean?
On Thu, Nov 12, 2009 at 04:52:20PM -0300, Alvaro Herrera wrote:
> FWIW I committed the parts of one of these patches that touched the core
Thanks for your help.
> grammar mostly, because I think those might have been holding Michael
> back a bit. Hopefully that'll make it easier for him to revie
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
> > If you want to submit patches in a series like this one, they need to be
> > considered standalone, I think. The Linux kernel devs work differently
> > than us here.
>
> Zoltan broke them up because Michael asked him to do so.
Actu
Greg Smith writes:
> Since most people have an upper limit on how much community time they
> can spend, every minute spent reviewing is one you're not working on
> your own patches during. The way you're describing the qualification
> process, it would be easy to conclude that there's a review
Robert Haas writes:
> Suppose you do this:
> create table animals (id serial primary key, name varchar not null);
> Then you can do this:
> with beings as (select * from animals) select * from beings where id = 1;
> But not this:
> with beings as (select * from animals a1, animals a2) select *
KaiGai Kohei wrote:
> I found a uncertain term in your comment.
> It seems to me the "model" has two meanings in this context.
> - The way to make access control decision (allowed? or denied?).
> - The granularity of access controls (tables? columns? or tuples?).
>
What I meant by "the SEPosgreS
Fujii Masao wrote:
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith wrote:
Right, those are the possibilities, all four of them have valid use cases in
the field and are worth implementing. I don't like the label
"semi-synchronous replication" myself, but it's a valuable feature to
implement, an
Hi Greg and Fujii,
Just a point on terminology: there's a difference in the usage of
semi-synchronous between DRBD and MySQL semi-synchronous replication, which
was originally developed by Google.
In the Google case semi-synchronous replication is a quorum algorithm where
clients receive a comm
Robert Haas wrote:
>
> That wasn't my intention. I really was assuming that we would just
> let those patches drop on the floor, and that they would not be picked
> up either by reviewers or committers.
Surely it should depend on the nature of the patch.
For an extreme strawman, segfault fixes
Greg Smith wrote:
> KaiGai Kohei wrote:
>> In the v8.4 development cycle, I got a suggestion to reduce
>> a burden of reviewer to split off a few functionalities, such
>> as "security_context" system column and row-level access controls.
>>
> I lost track of this patch and related bits somewhere
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith wrote:
> Right, those are the possibilities, all four of them have valid use cases in
> the field and are worth implementing. I don't like the label
> "semi-synchronous replication" myself, but it's a valuable feature to
> implement, and that is unfortu
On Thu, Nov 12, 2009 at 11:50 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> We just wouldn't assign round-robin reviewers to such patches. ?If
>> >> someone wants to volunteer, more power to them, but we would encourage
>> >> people to focus their efforts on the patches of people who were
>>
On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark wrote:
> I think my definition would be that a query against the replica will
> produce the same result as a query against the master -- and that that
> will be the case even after a system failure. That might not
> necessarily mean that the log entry i
KaiGai Kohei wrote:
> In the v8.4 development cycle, I got a suggestion to reduce
> a burden of reviewer to split off a few functionalities, such
> as "security_context" system column and row-level access controls.
>
I lost track of this patch and related bits somewhere along the way, had
to tri
Robert Haas wrote:
> >> We just wouldn't assign round-robin reviewers to such patches. ?If
> >> someone wants to volunteer, more power to them, but we would encourage
> >> people to focus their efforts on the patches of people who were
> >> themselves reviewing. ?It's important to keep in mind that
Fujii Masao wrote:
Umm... what is your definition of "synchronous"? I'm planning to provide
four synchronization modes as follows, for v8.5. Does this fit in your
thought?
The primary waits ... before returning "success" of a transaction;
* nothing - asynchronous replication
* recv ACK
On Thu, Nov 12, 2009 at 11:31 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> Personally, I would not propose to impose this rule of first-time
>> >> contributors, or even second-time contributors. ?But by about patch #3
>> >> I think everyone should be pitching in.
>> >
>> > I hate to ask, bu
The attached patch is a revised version of large object privileges
based on the feedbacks at the last commit fest.
List of updates:
* Rebased to the latest CVS HEAD
* Add pg_largeobject_aclcheck_snapshot() interface.
In the read-only access mode, large object feature uses
query's snaphot, not
Robert Haas wrote:
> >> Personally, I would not propose to impose this rule of first-time
> >> contributors, or even second-time contributors. ?But by about patch #3
> >> I think everyone should be pitching in.
> >
> > I hate to ask, but how would we enforce this? ?Do we no longer apply
> > patches
Suppose you do this:
create table animals (id serial primary key, name varchar not null);
Then you can do this:
with beings as (select * from animals) select * from beings where id = 1;
But not this:
with beings as (select * from animals a1, animals a2) select * from
beings where id = 1;
Beca
Itagaki Takahiro wrote:
> Here is a updated TRIGGER with WHEN cluase patch.
> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
I would like to volunteer for reviewing the patch in RR-stage.
It seems to me an interesting feature.
--
OSS Platform Development Division, NEC
KaiGai
On Nov 12, 2009, at 5:57 PM, Robert Haas wrote:
> On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus wrote:
>> On 11/12/09 8:30 AM, Tom Lane wrote:
>>> So while a payload string for NOTIFY has been on the to-do list since
>>> forever, I have to think that Greg's got a good point questioning
>>> whethe
Hello
I am sorry. I'll send a actualised version today.
Pavel
2009/11/13 Alvaro Herrera :
> Pavel Stehule escribió:
>> Hello
>>
>> actualised version: enhance check inside sql function
>
> What is this against? It has a few suspicious chunks, such as
>
> ***
> *** 358,364
>
>
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc. No artificial restrictions are imposed on what
syntactical combinations are allowed. However, ORDER BY is not allowed
with aggregates used as window functions (as per the existing
restriction on DISTINCT).
Included
On Thu, Nov 12, 2009 at 9:15 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
>> wrote:
>> > A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
>> >> Simon Riggs escreveu:
>> >> > So, I
>> >> > propose that we simply ig
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao wrote:
> Umm... what is your definition of "synchronous"? I'm planning to provide
> four synchronization modes as follows, for v8.5. Does this fit in your
I think my definition would be that a query against the replica will
produce the same result as a
On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian wrote:
> daveg wrote:
>> On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
>> >
>> > Really I think you guys are on the wrong track trying to map Postgres
>> > releases to commercial support terms. None of the Postgres releases
>> > are "sup
On Fri, Nov 13, 2009 at 2:35 AM, daveg wrote:
> I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
> to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
What would this mean? How would it be different than the status quo?
--
greg
--
Sent via pg
daveg wrote:
> On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
> >
> > Really I think you guys are on the wrong track trying to map Postgres
> > releases to commercial support terms. None of the Postgres releases
> > are "supported" in the sense that there's no warranty and no promises
On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith wrote:
> Whether or not you think it's sufficient for what you have in mind,
> "synchronous replication" requires a return ACK from the secondary before
> you say things are committed on the primary. If you don't do that, it's not
> true sync replicati
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote:
>
> Really I think you guys are on the wrong track trying to map Postgres
> releases to commercial support terms. None of the Postgres releases
> are "supported" in the sense that there's no warranty and no promises,
> it's all best effor
and we should stop. The world contains infinite amounts of lameness,
but that's the world's problem, not ours. There is zero evidence that
+1
this feature is only useful for stupid purposes, and some evidence
(namely, the opinions of esteemed community members) that it is useful
for at lea
On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane wrote:
>> And yes, i'm +1 for having a rule for EOL, like "5 versions are
>> supported".
>
> If we released on a consistent schedule, this *might* be possible.
> But we don't, so we can't say something like this.
We've already done this. I th
On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk wrote:
> * Fujii Masao [091112 20:52]:
>
>> Personally, I think
>> that
>> semi-synchronous replication is sufficient for HA.
>
> Often, but that's not synchronous replication so don't call it
Robert Haas wrote:
> On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
> wrote:
> > A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
> >> Simon Riggs escreveu:
> >> > So, I
> >> > propose that we simply ignore patches from developers until they have
> >> > done suffic
Fujii Masao wrote:
Personally, I think that semi-synchronous replication is sufficient for HA.
Whether or not you think it's sufficient for what you have in mind,
"synchronous replication" requires a return ACK from the secondary
before you say things are committed on the primary. If you do
On Thu, Nov 12, 2009 at 8:55 PM, Greg Smith wrote:
> I'm not sure that's the message you want to be sending, because anyone who
> dreams of being a committer is going to stay as far away from doing review
> as they can if that notion spreads.
To say nothing of CommitFest management.
...Robert
-
* Fujii Masao [091112 20:52]:
>Personally, I think
> that
> semi-synchronous replication is sufficient for HA.
Often, but that's not synchronous replication so don't call it such...
--
Aidan Van Dyk
On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus wrote:
> On 11/12/09 8:30 AM, Tom Lane wrote:
>> So while a payload string for NOTIFY has been on the to-do list since
>> forever, I have to think that Greg's got a good point questioning
>> whether it is actually a good idea.
>
> Sure, people will abus
Tom Lane wrote:
While I'm not against promoting more committers to deal with the influx of
patches,
the only way I know for people to get to the skill level of being fully
competent reviewers is to have done a lot of patch writing themselves.
The dynamic going on right now is that many people
On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith wrote:
> This a distressingly common thing people get wrong about replication. You
> can either have synchronous replication, which as you say has to be slow:
> you must wait for an fsync ACK from the secondary and a return trip before
> you can say som
Alvaro Herrera wrote:
> BTW I think the vacstmt.options change, which seems a reasonable idea to
> me, could be extracted from the patch and applied separately. That'd
> reduce the size of the patch somewhat.
It's a good idea. I separated the part into the attached patch.
It replaces VacuumStm
Josh Berkus wrote:
> paying attention to and which they shouldn't. I *thought* that Bruce
> was doing that for AsterData, but apparently not.
Josh, two days ago you complained I that I mentioned 'search_path' when
we were talking about postgresql.conf, now you have another complaint
about me. Di
On 11/12/09 8:30 AM, Tom Lane wrote:
> So while a payload string for NOTIFY has been on the to-do list since
> forever, I have to think that Greg's got a good point questioning
> whether it is actually a good idea.
Sure, people will abuse it as a queue. But people abuse arrays when
they should be
On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote:
> Here's the patch to support Python >=3.1 with PL/Python.
:\
I was hoping to be able to use Python 3 to draw a clear distinction between
plpython and the would-be "plpython3" that I've been working on. I understand
that you're not in favor
On Thu, Nov 12, 2009 at 6:53 PM, Tom Lane wrote:
> Now those criteria were developed to deal mainly with people committing
> their own patches. What we have at the moment is a lot of patches
> coming in from people who aren't ready to be committers, and maybe don't
> ever want to be. The questio
"Kevin Grittner" writes:
> On the subject topic, I have to say that I don't see where Robert
> hasn't met the qualifications mentioned so far on this thread as
> required to promote someone to the committer level; are there some
> requirements which exist but haven't been mentioned?
He hasn't act
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane writes:
> Yes. Particularly those complaining that they want to have very large
> payload strings --- that's pretty much a dead giveaway that it's not
> being used as a
Hi Dave,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> Updated patch attached. Per discussion, this:
> - Changes the envvar name to PGAPPNAME
> - Removes support for setting application_name in the startup packet,
> and instead sends an explicit SET command as part of the connection
> se
On Thu, 2009-11-12 at 23:16 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> >> needs significant preparation for them. Announcing an EOL early in time
> >> would give them the required time before the version used disappears.
> >
> > So, should we an
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> needs significant preparation for them. Announcing an EOL early in time
>> would give them the required time before the version used disappears.
>
> So, should we announce it for June?
No, it should be longer. June is practically around the
Pavel Stehule escribió:
> Hello
>
> actualised version: enhance check inside sql function
What is this against? It has a few suspicious chunks, such as
***
*** 358,364
funcexpr->funcid = funcid;
funcexpr->funcresulttype = rettype;
!
Alex Hunsaker writes:
> On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote:
>> I'd go for the first of those, for sure. Â Testing attnotnull is
>> significantly cheaper than enforcing a generic constraint expression,
>> and NOT NULL is a sufficiently common case to be worth worrying about
>> optimizin
On the subject topic, I have to say that I don't see where Robert
hasn't met the qualifications mentioned so far on this thread as
required to promote someone to the committer level; are there some
requirements which exist but haven't been mentioned?
Regarding the specific issues below, which see
On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote:
> I'd go for the first of those, for sure. Testing attnotnull is
> significantly cheaper than enforcing a generic constraint expression,
> and NOT NULL is a sufficiently common case to be worth worrying about
> optimizing it.
When I looked at doing
Alvaro Herrera writes:
> With all this fallout, I think it would be cleaner to step back and make
> it a regular GUC variable, not custom. Pretending that plpgsql is
> somehow not an integral part of the system is not completely true
> anyway. Yes, we're playing favorites in the PL camp here, bu
On Thu, 2009-11-12 at 23:09 +0100, Andreas 'ads' Scherbaum wrote:
> On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
>
> > Andreas 'ads' Scherbaum wrote:
> > > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> > >
> > >
> > >> The same goes for other OSS projects. There's quite a
Tom Lane escribió:
> I wrote:
> > Fair enough. I'll start writing the custom GUC then.
>
> While testing that, I noticed [...]
With all this fallout, I think it would be cleaner to step back and make
it a regular GUC variable, not custom. Pretending that plpgsql is
somehow not an integral part
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
> Andreas 'ads' Scherbaum wrote:
> > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> >
> >
> >> The same goes for other OSS projects. There's quite a few random OSS
> >> apps which were created on PG 7.4 and have never offered th
Mark Hammonds writes:
> 1. View Based Exports
> In addition to being able to dump specific tables, it seems useful to
> be able to quickly specify and dump entire views.
Isn't this pretty much the same thing as your #2? A view in PG isn't
materialized, it's nothing but a custom SELECT.
> 2.
Tom Lane wrote:
AFAIK the ecpg patches are all waiting on Michael Meskes to have time
to review/commit them. ecpg is pretty much his turf and no other
committers are likely to touch these patches.
Great to know, and since some of the regular reviewers already made a
pass through them there's pr
Grzegorz Jaskiewicz writes:
> consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
Locale issue maybe? Looks like it has some odd ideas about text
sort order.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Grzegorz Jaskiewicz wrote:
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
+ ERROR: incompatible library
"/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version
mismatch
+ DETAIL: Server is version 8.4, library is version 8.3.
You might take this as
On Thu, Nov 12, 2009 at 3:12 PM, Jeff Davis wrote:
> On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
>> > Not all contributors are fluent English readers and writers.
>> >
>> > I certainly do not discourage those people from reviewing, but I can
>> > understand how it might be more frustrati
Peter Eisentraut writes:
> Here's the patch to support Python >=3.1 with PL/Python. The
> compatibility code is mostly in line with the usual 2->3 C porting
> practice and is documented inline.
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it
Bernd Helmle writes:
> My first idea is to just introduce a special contype in pg_constraint
> representing a NOT NULL constraint on a column, which holds all required
> information to do the mentioned maintenance stuff on them and to keep most
> of the current infrastructure. Utility commands
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
regression.diffs.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I think that's the key argument here. We have several customers, which
> need a very careful and time consuming evaluation before they can go
> into production with a new platform, which is quite time consuming and
> needs significant preparation for them. Announcing an EOL early in time
> would
--On 12. November 2009 15:23:06 -0500 Andrew Dunstan
wrote:
What I and others have been arguing is necessary to do EOL right is a
serious amount of notice, by way of press releases etc. We can't expect
users to keep polling our web site to see if there's an EOL. That means
we need to prepar
Andreas 'ads' Scherbaum wrote:
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
upgrade path (Gnuworld comes to mind). They need an EOL announ
On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
> > Not all contributors are fluent English readers and writers.
> >
> > I certainly do not discourage those people from reviewing, but I can
> > understand how it might be more frustrating and less productive for
> > them. An important part of
On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera
wrote:
> Boszormenyi Zoltan escribió:
>> Alvaro Herrera írta:
>
>> > I have applied this patch after some tinkering. I mainly added support
>> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
>> > name" in ecpg.addons which app
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> The same goes for other OSS projects. There's quite a few random OSS
> apps which were created on PG 7.4 and have never offered their users an
> upgrade path (Gnuworld comes to mind). They need an EOL announcement to
> get them motivated to
Robert Haas escribió:
> I used to feel this way, too. I'm not sure whether it's really worse
> at first, or whether it just seems worse a first until you get used to
> it. There is no getting around the fact that this is a community of
> very smart people. I work at a company where I'm the only
Here's the patch to support Python >=3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2->3 C porting
practice and is documented inline.
I needed to create an arguably weird hack to manage the regression
tests. Instead of creating a new expected file for pretty much eve
On Thu, Nov 12, 2009 at 11:46:54AM -0800, David Wheeler wrote:
> On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
>
> > My question boils down to, "why is this string concatenation
> > different from all other string concatenations?"
>
> Does it have something to do with afikoman?
I was wonderi
Tom Lane wrote:
> Greg Smith writes:
> > The set of patches I have the least feel for are the five ECPG
> > submissions, some of which were reviewed already. I would particularly
> > appreciate any early information reviewers might provide about their
> > capability/willingness to work on that
Boszormenyi Zoltan escribió:
> Alvaro Herrera írta:
> > I have applied this patch after some tinkering. I mainly added support
> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
> > name" in ecpg.addons which apparently you forgot.
>
> Thanks. Your fix is correct if this pa
On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
> My question boils down to, "why is this string concatenation different
> from all other string concatenations?"
Does it have something to do with afikoman?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Thu, Nov 12, 2009 at 1:45 PM, Jeff Davis wrote:
> On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
>> I agree. I would quibble only with the details. I think we should
>> require patch authors to act as a reviewer for any CommitFest for
>> which they have submitted patches. We don't nee
Hello Everyone,
I recently spent some time comparing the various techniques used to
backup/export MySQL, SQLite, and PostgreSQL databases. So far, pg_dump
is the best tool I've used. I was well pleased with its efficient
syntax and functionality. However, I have two feature requests that I
Greg Smith writes:
> The set of patches I have the least feel for are the five ECPG
> submissions, some of which were reviewed already. I would particularly
> appreciate any early information reviewers might provide about their
> capability/willingness to work on that set. Those are not so ea
Hi
While trying to create a domain over an array type to enforce a certain
shape or certain contents of an array (like the array being only
one-dimensional or not containing NULLs), I've stumbled over what I
believe to be a bug in postgresql 8.4
It seems that check constraints on domains are *no
I'm not addressing the complaints Emmanuel has about patch submission,
but was inspired by what he said. I hesitated to post this to
-hackers, but my hope is that my comments are taken in the spirit of
reflection.
I've been thinking about the Postgres community and things that
differentiate it fro
Josh Berkus wrote:
On 11/12/09 9:45 AM, Greg Smith wrote:
For lack of a more qualified volunteer, I'll be handling the initial
round of patch assignments and reviewer organization.
Hmmm? Who's more qualified than you, exactly?
I was alluding to the fact that Robert isn't available
--On 4. November 2009 09:57:27 -0500 Tom Lane wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
I've just started
On Thu, Nov 12, 2009 at 1:27 PM, Josh Berkus wrote:
>
>> That's basically just it: Assume bashing is part of the process. Don't
>> think of it as bashing. Take the constructive criticism from it, ignore
>> the rest. Assume only one out of three feature ideas will make it.
>> Apply the prerequi
On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
> I agree. I would quibble only with the details. I think we should
> require patch authors to act as a reviewer for any CommitFest for
> which they have submitted patches. We don't need every patch author
> to review as many patches as they
Robert Haas writes:
> On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
> wrote:
>> Although it might cause a fair amount of backward-compatibility trouble, the
>> string representation could either use NULL to represent a null element as
>> is allowed in other contexts or require that empty-string
On Thu, Nov 12, 2009 at 01:33:41PM -0500, Robert Haas wrote:
> On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
> wrote:
> > Although it might cause a fair amount of backward-compatibility
> > trouble, the string representation could either use NULL to
> > represent a null element as is allowed in
I wrote:
> Fair enough. I'll start writing the custom GUC then.
While testing that, I noticed a pre-existing GUC limitation that maybe
we should do something about now: it does not work very nicely for
custom SUSET GUC variables. Normally, if a variable is SUSET, an
ordinary user can't do ALTER
Robert Haas escribió:
> On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
> wrote:
> > A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
> >> Simon Riggs escreveu:
> >> > So, I
> >> > propose that we simply ignore patches from developers until they have
> >> > done suf
On Thu, 2009-11-12 at 15:52 -0200, Euler Taveira de Oliveira wrote:
> Simon Riggs escreveu:
> > So, I
> > propose that we simply ignore patches from developers until they have
> > done sufficient review to be allowed to develop again.
>
> Is it really impolite for a first-contributor, no?
I beli
On Thu, Nov 12, 2009 at 11:40 AM, Merlin Moncure wrote:
> I'm sorry, the 128 character limit is simply lame (other than for
> unsolvable implementation/performance complexity which I doubt is the
> case here), and if that constraint is put in by the implementation,
> than the implementation is bus
2009/11/13 Euler Taveira de Oliveira :
> Simon Riggs escreveu:
>> So, I
>> propose that we simply ignore patches from developers until they have
>> done sufficient review to be allowed to develop again.
>>
> Is it really impolite for a first-contributor, no?
>
I support Simon's proposal, but I thi
On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
wrote:
> Although it might cause a fair amount of backward-compatibility trouble, the
> string representation could either use NULL to represent a null element as
> is allowed in other contexts or require that empty-string elements be
> represented a
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
> Simon Riggs escreveu:
> > So, I
> > propose that we simply ignore patches from developers until they have
> > done sufficient review to be allowed to develop again.
>
> Is it really impolite for a first-contributor, no?
>
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
wrote:
> A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
>> Simon Riggs escreveu:
>> > So, I
>> > propose that we simply ignore patches from developers until they have
>> > done sufficient review to be allowed to deve
> I like this idea. Perhaps also if a person is reviewing a patch for
> the first time, we could make some effort to get a more experienced
> person paired up with them.
When I was CFM last year, I assigned patches for review first if the
patch author was doing a review themselves. Patches whose
Tom Lane wrote:
David Fetter writes:
The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should do
with them?
regards, tom lane
This seems somewhat related to the long-running discussion from back in
Februar
1 - 100 of 152 matches
Mail list logo
