Horton

Thread

  1. Better name for PQsslAttributes()

    Lars Kanis <lars@greiz-reinsdorf.de> — 2015-11-06T21:31:52Z

    As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to
bridge the new SSL related functions to Ruby methods. However I wonder
whether PQsslAttributes() is the best name for the function. Based on
this name, I would expect to get key+value pairs instead of only the
keys. IMHO PQsslAttributeNames() would express better, what the function
does.

--
Kind Regards,
Lars

  2. Re: Better name for PQsslAttributes()

    Heikki Linnakangas <hlinnaka@iki.fi> — 2015-11-06T21:38:45Z

    On 11/06/2015 11:31 PM, Lars Kanis wrote:
> As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to
> bridge the new SSL related functions to Ruby methods. However I wonder
> whether PQsslAttributes() is the best name for the function. Based on
> this name, I would expect to get key+value pairs instead of only the
> keys. IMHO PQsslAttributeNames() would express better, what the function
> does.

Hmm, I think you're right.

The question is, do we want to still change it? It's a new function in 
9.5, and we're just about to enter beta, so I guess we could, although 
there might already be applications out there using it. If we do want to 
rename it, now is the last chance to do it.

Thoughts? I'm leaning towards changing it now.

- Heikki

  3. Re: Better name for PQsslAttributes()

    Magnus Hagander <magnus@hagander.net> — 2015-11-06T21:40:10Z

    On Fri, Nov 6, 2015 at 10:38 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

> On 11/06/2015 11:31 PM, Lars Kanis wrote:
>
>> As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to
>> bridge the new SSL related functions to Ruby methods. However I wonder
>> whether PQsslAttributes() is the best name for the function. Based on
>> this name, I would expect to get key+value pairs instead of only the
>> keys. IMHO PQsslAttributeNames() would express better, what the function
>> does.
>>
>
> Hmm, I think you're right.
>
> The question is, do we want to still change it? It's a new function in
> 9.5, and we're just about to enter beta, so I guess we could, although
> there might already be applications out there using it. If we do want to
> rename it, now is the last chance to do it.
>
> Thoughts? I'm leaning towards changing it now.


Uh, just to be clear, we been in beta for a month now, beta1 was released
Oct 8.  We are not just about to enter it...


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  4. Re: Better name for PQsslAttributes()

    Peter Geoghegan <pg@heroku.com> — 2015-11-06T21:41:02Z

    On Fri, Nov 6, 2015 at 1:38 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Thoughts? I'm leaning towards changing it now.

+1 to the idea of changing it.

-- 
Peter Geoghegan

  5. Re: Better name for PQsslAttributes()

    Tom Lane <tgl@sss.pgh.pa.us> — 2015-11-06T22:06:17Z

    Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 11/06/2015 11:31 PM, Lars Kanis wrote:
>> As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to
>> bridge the new SSL related functions to Ruby methods. However I wonder
>> whether PQsslAttributes() is the best name for the function. Based on
>> this name, I would expect to get key+value pairs instead of only the
>> keys. IMHO PQsslAttributeNames() would express better, what the function
>> does.

> Hmm, I think you're right.

> The question is, do we want to still change it? It's a new function in 
> 9.5, and we're just about to enter beta, so I guess we could, although 
> there might already be applications out there using it. If we do want to 
> rename it, now is the last chance to do it.

> Thoughts? I'm leaning towards changing it now.

I agree that this is about the last possible chance to rename it, if
indeed that chance is not already past.

However, it seems somewhat unlikely that anyone would be depending on the
thing already, so I think probably we could get away with renaming it.

+0.5 or so to changing it.  But if we do, it has to happen before Monday.

			regards, tom lane

  6. Re: Better name for PQsslAttributes()

    Lars Kanis <lars@greiz-reinsdorf.de> — 2015-11-07T20:17:04Z

    Thank you for the quick response! Attached the last minute - now or
never patch to change the function name.

In addition I perceived a small inconsistency with the naming of the
SGML id of PQsslAttribute. This is addressed in the second patch file.

--
Kind Regards,
Lars

  7. Re: Better name for PQsslAttributes()

    Tom Lane <tgl@sss.pgh.pa.us> — 2015-11-07T20:17:20Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> The question is, do we want to still change it? It's a new function in 
>> 9.5, and we're just about to enter beta, so I guess we could, although 
>> there might already be applications out there using it. If we do want to 
>> rename it, now is the last chance to do it.

> +0.5 or so to changing it.  But if we do, it has to happen before Monday.

Are we doing this (seems like nobody objected), and if so who's going to
make it happen?  Time grows short.

			regards, tom lane

  8. Re: Better name for PQsslAttributes()

    Tom Lane <tgl@sss.pgh.pa.us> — 2015-11-07T20:39:22Z

    Lars Kanis <lars@greiz-reinsdorf.de> writes:
> Thank you for the quick response! Attached the last minute - now or
> never patch to change the function name.

Ah, thanks for doing the legwork.  It's pretty late in the day Heikki's
time, so I'll review and hopefully push this.

			regards, tom lane

  9. Re: Better name for PQsslAttributes()

    Tom Lane <tgl@sss.pgh.pa.us> — 2015-11-07T21:14:48Z

    Lars Kanis <lars@greiz-reinsdorf.de> writes:
> Thank you for the quick response! Attached the last minute - now or
> never patch to change the function name.

Pushed.  I took the opportunity to fix the const-ness annotation of the
function result type, too.

			regards, tom lane

  10. Re: Better name for PQsslAttributes()

    Lars Kanis <lars@greiz-reinsdorf.de> — 2015-11-07T23:04:36Z

    Am 07.11.2015 um 22:14 schrieb Tom Lane:
> Pushed. I took the opportunity to fix the const-ness annotation of the
> function result type, too.

Great, thank you!