From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal (9.5) : psql unicode border line styles |
Date: | 2014-09-11 18:08:27 |
Message-ID: | 20140911180827.GD16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> 2014-09-11 16:42 GMT+02:00 Stephen Frost <sfrost(at)snowman(dot)net>:
> > I don't particularly like this (having these fields set in
> > refresh_utf8format to hard-coded strings in the function), why not have
> > those handled the same as the rest, where the strings themselves are in
> > the unicode_style structure?
> >
>
> I am not sure if I understand well.
>
> With refresh_utf8format I can do shortly 6 possible combinations - or more
> (when it will be requested)
>
> I have no idea how to write as rest without repeating all 6 combinations -
> what was one noticed issue of some older variant, where I designed
> unicode1, unicode2, ...
>
> Any idea, tip how to it?
All I was suggesting was pulling these strings out of the function:
+ /* âµ */
+ popt->header_nl_right = "\342\206\265";
+
+ popt->nl_left = " ";
+
+ /* âµ */
+ popt->nl_right = "\342\206\265";
+
+ /* ⦠*/
+ popt->wrap_left = "\342\200\246";
+ popt->wrap_right = "\342\200\246";
and adding them to unicode_style and then referencing them there,
similar to how the rest of printTextFormat popt (by the way- don't
really like that variable name, particularly as it's used elsewhere with
a very different meaning.. why not 'format' or 'ptf'?) is
set up in refresh_utf8format, that's all.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-09-11 18:10:35 | Re: proposal: ignore null fields in not relation type composite type based constructors |
Previous Message | Arthur Silva | 2014-09-11 17:54:36 | Re: Memory Alignment in Postgres |