Re: Fast default stuff versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fast default stuff versus pg_upgrade
Дата
Msg-id 2895.1529616031@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fast default stuff versus pg_upgrade  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> In terms of pgindent, I'm surprised about these lines:
> +    missingval = OidFunctionCall3(
> +                                  F_ARRAY_IN,

> Why did you put a newline there?  In ancient times there was a reason
> for that in some cases, because pgindent would move the argument to the
> left of the open parens, but it doesn't do that anymore and IMO it's
> just ugly.  We have quite a few leftovers from this ancient practice,
> I've been thinking about removing these ...

I think some people feel this is good style, but I agree with you
about not liking it.  A related practice I could do without is eating
an extra line for an argument-closing paren, as in this example in
tsquery_op.c:

Datum
tsq_mcontained(PG_FUNCTION_ARGS)
{
    PG_RETURN_DATUM(
                    DirectFunctionCall2(
                                        tsq_mcontains,
                                        PG_GETARG_DATUM(1),
                                        PG_GETARG_DATUM(0)
                                        )
        );
}

Aside from the waste of vertical space, it's never very clear to me
(nor, evidently, to pgindent) how such a paren ought to be indented.
So to my eye this could be four lines shorter and look better.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fast default stuff versus pg_upgrade
Следующее
От: Nico Williams
Дата:
Сообщение: Re: libpq compression