Re: Patch author name on commitfest page

On Fri, Oct 1, 2010 at 10:37 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Oct 1, 2010 at 16:36, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Thu, Sep 30, 2010 at 23:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Thu, Sep 30, 2010 at 5:38 PM, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> wrote:
>>>>> Can we please change the comment lines below the patch heading to have the
>>>>> real name instead of the postgresql.org ID?
>>>>>
>>>>> Patch by Pavel Stehule
>>>>> Patch by Gurjeet Singh
>>>>>
>>>>> instead of
>>>>>
>>>>> Patch by okbobcz
>>>>> Patch by singh.gurjeet
>>>>>
>>>>> https://commitfest.postgresql.org/action/commitfest_view?id=8
>>>>
>>>> I don't think that information is available to the app, at least at
>>>> present... when you log in, it is empowered to ask the community login
>>>> DB "is this combination of a username and a password valid?" but all
>>>> it gets back is "yes" or "no".
>>>
>>> Sure it is. When you call community_login(), it'll return you the
>>> yes/no field, the full name, the email address, an author text (not
>>> used anymore, so don't rely on that), community docs superuser flag
>>> (also not used, don't rely on, kind of a failed experiment) and last
>>> successful login time prior to this one.
>>>
>>> It's quite possible all users haven't included their full name when
>>> they registered, but for those that have the information is available.
>>
>> Hrm, so in theory I could maintain a (possible stale) cache of this
>> information.  Seems sort of hairy, though.
>
> Keep it in whatever session state where you keep the login data?

Oh, and then copy it from there if someone posts a comment? I suppose
that could work, although it would only apply to comments added from
the point of the code change going forward.

Seems like it would be nicer to have a table with username/real name
in the CF DB. But I guess that would require configuring some kind of
replication...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company