Daniel Gustafsson writes:
>> On 2 Jul 2019, at 22:35, Alvaro Herrera wrote:
>> Anyway I'm not objecting to the patch -- I agree that we're already not
>> testing translatability and that this patch shouldn't be forced to start
>> doing it.
> I forgot to add that to my previous email, the patch
> On 2 Jul 2019, at 22:35, Alvaro Herrera wrote:
> Anyway I'm not objecting to the patch -- I agree that we're already not
> testing translatability and that this patch shouldn't be forced to start
> doing it.
I forgot to add that to my previous email, the patch as it stands in v8 looks
good to
On 2019-Jul-02, Daniel Gustafsson wrote:
> > On 2 Jul 2019, at 22:16, Tom Lane wrote:
>
> > even if we made a test case that presumed
> > --enable-nls and tried to exercise this, the lack of translations
> > for the new words would get in the way for a long while.
>
> For testing though,
> On 2 Jul 2019, at 22:16, Tom Lane wrote:
> even if we made a test case that presumed
> --enable-nls and tried to exercise this, the lack of translations
> for the new words would get in the way for a long while.
For testing though, couldn’t we have an autogenerated .po which has a unique
and
Alvaro Herrera writes:
> On 2019-Jul-02, Tom Lane wrote:
>> * The persistence description values ought to be translatable, as
>> is the usual practice in describe.c. This is slightly painful
>> because it requires tweaking the translate_columns[] values in a
>> non-constant way, but it's not
On 2019-Jul-02, Tom Lane wrote:
> * The persistence description values ought to be translatable, as
> is the usual practice in describe.c. This is slightly painful
> because it requires tweaking the translate_columns[] values in a
> non-constant way, but it's not that bad.
LGTM. I only fear
David Fetter writes:
> [ v7-0001-Show-detailed-relation-persistence-in-dt.patch ]
I looked this over and had a few suggestions, as per attached v8:
* The persistence description values ought to be translatable, as
is the usual practice in describe.c. This is slightly painful
because it
Hello David,
Patch v7 applies, compiles, make check ok. No docs needed.
No tests, pending some TAP infrastructure.
I could no test with a version between 8.4 & 9.1.
No further comments. Marked as ready.
--
Fabien.
On Mon, Apr 29, 2019 at 08:48:17AM +0200, Fabien COELHO wrote:
>
> Hello David,
>
> > My mistake. Fixed.
>
> About v6: applies, compiles, make check ok.
>
> Code is ok.
>
> Maybe there could be a comment to tell that prior version are not addressed,
> something like:
>
> ...
> }
> /*
Hello David,
My mistake. Fixed.
About v6: applies, compiles, make check ok.
Code is ok.
Maybe there could be a comment to tell that prior version are not
addressed, something like:
...
}
/* else do not bother guessing the temporary status on old version */
No tests, pending an
On Sun, Apr 28, 2019 at 07:26:55PM +0200, Fabien COELHO wrote:
>
> Hello David,
>
> > > Patch applies. There seems to be a compilation issue:
> > >
> > > describe.c:5974:1: error: expected declaration or statement at end of
> > > input
> > > }
> >
> > This is in brown paper bag territory.
On Sun, Apr 28, 2019 at 01:14:01PM -0400, Tom Lane wrote:
> Not particularly on topic, but: including a patch version number in your
> subject headings is pretty unfriendly IMO, because it breaks threading
> for people whose MUAs do threading by matching up subject lines.
Thanks for letting me
Hello David,
Patch applies. There seems to be a compilation issue:
describe.c:5974:1: error: expected declaration or statement at end of
input
}
This is in brown paper bag territory. Fixed.
I do not understand why you move both size and description out of the
verbose mode, it should
Not particularly on topic, but: including a patch version number in your
subject headings is pretty unfriendly IMO, because it breaks threading
for people whose MUAs do threading by matching up subject lines.
I don't actually see the point of the [PATCH] annotation at all, because
the thread is
y the new additions should follow that style:
> case -> CASE (and also when then else end as…)
Done.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 3baf2d98dd699b3b04c2d3ac038d
15 matches
Mail list logo
