Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID
Date
Msg-id 4E1C768A.8080908@commandprompt.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID
List pgsql-hackers
On 07/12/2011 06:54 AM, Alvaro Herrera wrote:
> Excerpts from Magnus Hagander's message of mar jul 12 09:34:56 -0400 2011:
>
>>> Agreed.  On one level I like the sponsor message, but on the other
>>> having "Sponsored by RedHat" on every Tom Lane item will get tiring.
>>> ;-)

Create a macro ;)

>>>
>>> Can we add text if the employer is _not_ the feature sponsor?
>>
>> That would be quite unfair to those who *do* employ committers....
>> Basically you'd get credit only if you didn't employ a committer.
>
> Well, that has worked well for my case -- I haven't ever credited my
> employer, only those that have specifically hired us for a particular
> patch.  My employer gets a lot of "credit" in the form of email
> signatures, like the one below ;-)

Yeah it depends on the committer. CMD gets credit through 
@commandprompt.com, the sig file and a host of other areas but Tom uses 
his personal information, so...

>
> But I see your point and I will stick to whatever policy we come up with
> (assuming we come up with one).
>
>> This all becomes much easier if we keep the ads out of the commit
>> messages, and stick to the technical side there. And find another
>> venue for the other credit.
>
> I'm open to ideas.

I think the commit log isn't actually useful for the "advertising" 
portion of this. Users don't read commit logs for the most part. 
However, it is an easy way for people who are writing release notes, 
press releases, etc... to find the information.

Is it a good place for the information? No.

Is it the easiest place to store it until somebody steps up and creates 
a proper way to track it so that it can be desimnated properly 
throughout the community? Probably.

We do need a way to track this information.

JD


-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Full GUID support
Next
From: Andres Freund
Date:
Subject: Deferred partial/expression unique constraints