Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID
Дата
Msg-id 4E1C768A.8080908@commandprompt.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Full GUID support
Следующее
От: Andres Freund
Дата:
Сообщение: Deferred partial/expression unique constraints