Peter Eisentraut writes:
> What is the plan behind keeping the old format? Are we going to remove
> it after one release if no one complains, or are we seriously expecting
> that someone has code that actually parses this?
Plan? Do we need a plan? The extra support consists of about two lines
On sön, 2009-11-22 at 00:23 -0500, Tom Lane wrote:
> Roger Leigh writes:
> > Attached is an updated patch with a couple of tweaks to ensure output
> > is formatted and spaced correctly when border=0, which was off in the
> > last patch.
>
> Applied wih minor editorialization. Notably, I renamed
Roger Leigh writes:
> Attached is an updated patch with a couple of tweaks to ensure output
> is formatted and spaced correctly when border=0, which was off in the
> last patch.
Applied wih minor editorialization. Notably, I renamed the
backwards-compatible option from "ascii-old" to "old-ascii"
On Sun, Nov 15, 2009 at 12:50:14AM +, Roger Leigh wrote:
> On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
> > Roger Leigh writes:
> > > The side effect from this change is that some of the testsuite
> > > expected data will need updating due to the extra pad spaces
> >
> > No, we a
On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The side effect from this change is that some of the testsuite
> > expected data will need updating due to the extra pad spaces
>
> No, we are *not* doing that. Somebody made a change to the print.c
> logic last
Roger Leigh writes:
> The side effect from this change is that some of the testsuite
> expected data will need updating due to the extra pad spaces
No, we are *not* doing that. Somebody made a change to the print.c
logic last year that started adding "harmless" white space to the
last column, an
On Sat, Nov 14, 2009 at 05:40:24PM +, Roger Leigh wrote:
> On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Greg Stark writes:
> > > > While i agree this looks nicer I wonder what it does to things like
> > > > excel/gnumeric/ooffice auto-recognizing tab
On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Greg Stark writes:
> > > While i agree this looks nicer I wonder what it does to things like
> > > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > > files. I'm not sure our old format was s
Andrew Dunstan wrote:
> >You can set the field separator to ',' but you can't do a
> > \pset format csv
> >and get CSV with correct quoting, escaping etc AFAICS. It'll
> >still break on line wrapping if wrapping is enabled, and with
> >newlines in the data.
> >
> >If that would be a useful addit
Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
> > is actually an improvement I'm asking
Roger Leigh wrote:
On Sat, Oct 31, 2009 at 12:25:22PM -0400, Andrew Dunstan wrote:
Roger Leigh wrote:
Wouldn't it be much simpler all around to add a "csv" output format
in addition to the above for this purpose? Spreadsheets can read
it in with no trouble at all.
We've had C
On Sat, Oct 31, 2009 at 12:25:22PM -0400, Andrew Dunstan wrote:
>
>
> Roger Leigh wrote:
>>
>> Wouldn't it be much simpler all around to add a "csv" output format
>> in addition to the above for this purpose? Spreadsheets can read
>> it in with no trouble at all.
>
> We've had CSV output since ver
Roger Leigh wrote:
Wouldn't it be much simpler all around to add a "csv" output format
in addition to the above for this purpose? Spreadsheets can read
it in with no trouble at all.
We've had CSV output since version 8.0.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-
On Sat, Oct 31, 2009 at 05:11:10AM -0700, Greg Stark wrote:
> On Mon, Oct 26, 2009 at 11:43 PM, Peter Eisentraut wrote:
> > On Mon, 2009-10-26 at 10:12 -0700, Greg Stark wrote:
> >> While i agree this looks nicer I wonder what it does to things like
> >> excel/gnumeric/ooffice auto-recognizing tab
On Mon, Oct 26, 2009 at 11:43 PM, Peter Eisentraut wrote:
> On Mon, 2009-10-26 at 10:12 -0700, Greg Stark wrote:
>> While i agree this looks nicer I wonder what it does to things like
>> excel/gnumeric/ooffice auto-recognizing table layouts and importing
>> files. I'm not sure our old format was s
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
On Mon, Oct 26, 2009 at 11:33:40PM +, Roger Leigh wrote:
> On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> > Roger Leigh writes:
> > > On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> > >> Yeah. We can do what we like with the UTF8 format but I'm considerably
> > >> mor
On Mon, 2009-10-26 at 10:12 -0700, Greg Stark wrote:
> While i agree this looks nicer I wonder what it does to things like
> excel/gnumeric/ooffice auto-recognizing table layouts and importing
> files. I'm not sure our old format was so great for this so maybe this
> is actually an improvement I'm
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> >> Yeah. We can do what we like with the UTF8 format but I'm considerably
> >> more worried about the aspect of making random changes to the
> >> plain-A
Roger Leigh writes:
> On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
>> Yeah. We can do what we like with the UTF8 format but I'm considerably
>> more worried about the aspect of making random changes to the
>> plain-ASCII output.
> I checked (using strace)
> gnumeric (via libgda and
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
Greg Stark writes:
> While i agree this looks nicer I wonder what it does to things like
> excel/gnumeric/ooffice auto-recognizing table layouts and importing
> files. I'm not sure our old format was so great for this so maybe this
> is actually an improvement I'm asking for.
Yeah. We can do wha
2009/10/25 Roger Leigh :
> rleigh=# \l
> List of databases
> Name │ Owner │ Encoding │ Collation │ Ctype │ Access
> privileges
> ─┼──┼──┼─┼─┼───
> merkelpb
On sön, 2009-10-25 at 23:48 +, Roger Leigh wrote:
> Just for reference, this is what the output looks like (abridged)
> using the attached patch. Should display fine if your mail client handles
> UTF-8 messages correctly:
>
> rleigh=# \l
> List of database
On Sun, Oct 25, 2009 at 11:48:27PM +, Roger Leigh wrote:
> There's just one tiny display glitch I can see, and that's if you have
> mixed wrapping and newlines, you miss the lefthand wrap mark if the line
> is the last wrapped line and it ends in a newline. It might not be
> possible to pick t
On Sat, Oct 24, 2009 at 06:23:24PM +0100, Roger Leigh wrote:
> On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> > I like the new Unicode tables, but the marking of continuation lines
> > looks pretty horrible:
> >
> > List of databases
> > Name
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> I like the new Unicode tables, but the marking of continuation lines
> looks pretty horrible:
>
> List of databases
> Name │ Owner │ Encoding │ Collation │ Ctype │ Access
> privileges
> ─
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> (HTML mail to preserve formatting; let's see if it works.)
>
> I like the new Unicode tables, but the marking of continuation lines
> looks pretty horrible:
Yes, I'm not so keen myself. The ASCII characters used are '|', ':' and
(HTML mail to preserve formatting; let's see if it works.)
I like the new Unicode tables, but the marking of continuation lines
looks pretty horrible:
List of databases
Name │ Owner │ Encoding │ Collation │ Ctype │ Access
privileges
───┼───┼─
On Tue, Oct 13, 2009 at 05:08:20PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > The attached updated patch renames all user-visible uses of
> > "utf8" to "unicode". It also updates the documentation
> > regarding "locale" to "psql client character set encoding"
> > so the docs now match the c
Roger Leigh writes:
> The attached updated patch renames all user-visible uses of
> "utf8" to "unicode". It also updates the documentation
> regarding "locale" to "psql client character set encoding"
> so the docs now match the code exactly.
Applied with light editorialization. The main non-cos
On Fri, Oct 09, 2009 at 04:35:46PM -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > I think the setting ought be called linestyle unicode (instead of
> > utf8), since the same setting would presumably work in case we ever
> > implement UTF-16 support on the client side.
>
> Yeah, a
Peter Eisentraut wrote:
> I think the setting ought be called linestyle unicode (instead of
> utf8), since the same setting would presumably work in case we ever
> implement UTF-16 support on the client side.
Yeah, anytime one gets sloppy with the distinction between a character
set and a char
On Tue, 2009-10-06 at 19:35 +0100, Roger Leigh wrote:
> This patch included a bit of code not intended for inclusion
> (setting of client encoding based on locale), which the attached
> (and hopefully final!) revision of the patch excludes.
Well, the documentation still claims that this is depende
On Tuesday 06 October 2009 11:35:03 Roger Leigh wrote:
> On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> > On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > > Roger Leigh writes:
> > > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > > >> Elsewhere
On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > Roger Leigh writes:
> > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > >> Elsewhere in the psql code, notably in mbprint.c, we make the decision
> >
On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> >> Elsewhere in the psql code, notably in mbprint.c, we make the decision
> >> on whether to apply certain Unicode-aware processing based on wheth
Roger Leigh writes:
> On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
>> Elsewhere in the psql code, notably in mbprint.c, we make the decision
>> on whether to apply certain Unicode-aware processing based on whether
>> the client encoding is UTF8. The same should be done here.
On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> I have a comment on this bit:
>
> > @@ -125,6 +128,17 @@ main(int argc, char *argv[])
> >
> > /* We rely on unmentioned fields of pset.popt to start out
> > 0/false/NULL */
> > pset.popt.topt.format = PRINT_ALIGN
I have a comment on this bit:
> @@ -125,6 +128,17 @@ main(int argc, char *argv[])
>
> /* We rely on unmentioned fields of pset.popt to start out
> 0/false/NULL */
> pset.popt.topt.format = PRINT_ALIGNED;
> +
> + /* Default table style to plain ASCII */
> + pset.popt.t
On Fri, Oct 02, 2009 at 05:34:16PM -0700, Brad T. Sliger wrote:
> On Friday 02 October 2009 04:21:35 Roger Leigh wrote:
> > I have attached a patch which implements the feature as a pset
> > variable. This also slightly simplifies some of the patch since
> > the table style is passed to functions
On Friday 02 October 2009 04:21:35 Roger Leigh wrote:
> On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote:
> > Roger Leigh writes:
> > >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> > >>> Thinking about this some more, ISTM a much better way of approaching
> > >>> it would be
On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> >>> Thinking about this some more, ISTM a much better way of approaching
> >>> it would be to provide a flag for psql to turn off the fancy
> >>> format
On Wed, 2009-09-30 at 18:50 -0400, Tom Lane wrote:
> It would be a good idea to tie this to a psql magic variable (like
> ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc.
> I'm not actually sure that we need a dedicated command line switch
> for it, since you could use "-v varname"
Roger Leigh writes:
>> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
>>> Thinking about this some more, ISTM a much better way of approaching
>>> it would be to provide a flag for psql to turn off the fancy
>>> formatting, and have pg_regress use that flag.
> The attached patch imple
Peter Eisentraut writes:
> On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
>> All scripts I've seen parsing psql output use unaligned, undecorated
>> mode. I have yet to see one messing with the |'s.
> Plus, we would have broken that with the : continuation lines.
Only for data contain
Robert Haas writes:
> The way it works right now (and has worked for the last 5 years or
> more) is reliable, familiar, and, at least IME, bullet-proof. I don't
> even see a good case for changing the default, let alone not providing
> a way to retreat to the old behavior.
This is pretty much my
On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
> All scripts I've seen parsing psql output use unaligned, undecorated
> mode. I have yet to see one messing with the |'s.
Plus, we would have broken that with the : continuation lines.
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Wed, Sep 30, 2009 at 01:30:17PM -0400, Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
>> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
>>
>>> Thinking about this some more, ISTM a much better way of approaching
>>> it would be to provide a flag for psql to turn off the fancy
On Wed, Sep 30, 2009 at 1:27 PM, Peter Eisentraut wrote:
> On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
>> > Andrew Dunstan writes:
>> >> Thinking about this some more, ISTM a much better way of approaching it
>> >> would be to provid
Andrew Dunstan escribió:
>
>
> Peter Eisentraut wrote:
> >On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> >>Thinking about this some more, ISTM a much better way of
> >>approaching it would be to provide a flag for psql to turn off
> >>the fancy formatting, and have pg_regress use that
Peter Eisentraut wrote:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Well, it might not be a b
On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
> On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Thinking about this some more, ISTM a much better way of approaching it
> >> would be to provide a flag for psql to turn off the fancy formatting,
> >> and hav
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> Thinking about this some more, ISTM a much better way of approaching it
> would be to provide a flag for psql to turn off the fancy formatting,
> and have pg_regress use that flag.
Well, it might not be a bad idea, but adding a feature j
Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
Andrew Dunstan writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Yeah,
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Thinking about this some more, ISTM a much better way of approaching it
>> would be to provide a flag for psql to turn off the fancy formatting,
>> and have pg_regress use that flag.
>
> Yeah, that's not a bad idea. Th
Andrew Dunstan writes:
> Thinking about this some more, ISTM a much better way of approaching it
> would be to provide a flag for psql to turn off the fancy formatting,
> and have pg_regress use that flag.
Yeah, that's not a bad idea. There are likely to be other client
programs that won't wan
Roger Leigh writes:
> The language in SUSv2 in fact explicitly states that this is
> allowed. In fact, I've seen documentation that some UNIX systems such
> as HPUX already do have a UTF-8 C locale as an option.
I don't argue with the concept of a C.UTF8 locale --- in fact I think
it sounds pret
Andrew Dunstan wrote:
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago gone
On Tue, Sep 29, 2009 at 04:32:49PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> >> C locale means POSIX behavior and nothing but.
>
> > Indeed it does. However, making LC_CTYPE be UTF-8 rather than
> > ASCII is both possible and still strictly conforming to the
> > letter of the standard. The
Andrew Dunstan writes:
> Roger Leigh wrote:
>> Here we just force the locale to C. This does have the disadvantage
>> that --no-locale is made redundant, and any tests which are dependent
>> upon locale (if any?) will be run in the C locale.
> That is not a solution.
Right. I think you may hav
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago gone to some lengths
to prov
On Tue, Sep 29, 2009 at 04:28:57PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
> >> The bigger question is exactly how we expect this stuff to interact with
> >> pg_regress' --no-locale switch. We already do clear all these variables
>
Tom Lane escribió:
> Alvaro Herrera writes:
> > Robert Haas escribi�:
> >> This seems to mean that we can't apply this patch, since failing the
> >> regression tests is not an acceptable behavior.
>
> > Does the patch pass regression tests in normal conditions?
>
> If you consider that "normal"
Alvaro Herrera wrote:
Does the patch pass regression tests in normal conditions? If it does,
I see no reason to reject it. If it fails in --locale only, and even
then only when the given locale is UTF8, which IIRC it's a seldom-used
case, we can see about fixing that separately.
Numerou
Alvaro Herrera writes:
> Robert Haas escribió:
>> This seems to mean that we can't apply this patch, since failing the
>> regression tests is not an acceptable behavior.
> Does the patch pass regression tests in normal conditions?
If you consider that "normal" means "LANG=C in environment", then
Robert Haas escribió:
> On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
> >>> The bigger question is exactly how we expect this stuff to interact with
> >>> pg_regress' --no-locale switch. We already do clear a
On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
>>> The bigger question is exactly how we expect this stuff to interact with
>>> pg_regress' --no-locale switch. We already do clear all these variables
>>> when --no
Roger Leigh writes:
>> C locale means POSIX behavior and nothing but.
> Indeed it does. However, making LC_CTYPE be UTF-8 rather than
> ASCII is both possible and still strictly conforming to the
> letter of the standard. There would be some collation and
> other restrictions ("digit" and other
Peter Eisentraut writes:
> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
>> The bigger question is exactly how we expect this stuff to interact with
>> pg_regress' --no-locale switch. We already do clear all these variables
>> when --no-locale is specified. I am wondering just what --locale
On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote:
> >> pg_regress clears LC_ALL by default, but does not clear LANG
> >> by default. Please find attached a patch that
> >> causes pg_regress to also clear LAN
On Tue, Sep 29, 2009 at 01:41:27PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > In Debian, we do have plans to introduce a C.UTF-8 locale,
>
> Egad, isn't that a contradiction in terms?
Not entirely!
> C locale means POSIX behavior and nothing but.
Indeed it does. However, making LC_CTYPE
Roger Leigh writes:
> In Debian, we do have plans to introduce a C.UTF-8 locale,
Egad, isn't that a contradiction in terms? C locale means POSIX
behavior and nothing but.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Tue, Sep 29, 2009 at 12:01:30PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote:
> >> pg_regress clears LC_ALL by default, but does not clear LANG
> >> by default. Please find attached a patch that
> >> causes pg_regress to also cl
Peter Eisentraut writes:
> On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote:
>> pg_regress clears LC_ALL by default, but does not clear LANG
>> by default. Please find attached a patch that
>> causes pg_regress to also clear LANG by default.
> It probably doesn't matter much, but I think
On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote:
> During this review I found that `gmake check` will fail when
> LANG=en_US.UTF-8 in the environment. In this case
> the patched psql produces UTF8 line art and the tests expect ASCII
> line art.
>
> pg_regress clears LC_ALL by def
On Sunday 27 September 2009 19:03:33 Robert Haas wrote:
> On Sun, Sep 27, 2009 at 9:24 PM, Selena Deckelmann
>
> wrote:
> > Hi!
> >
> > On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh wrote:
> >> On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
> >>> Brad says:
> >>>
> >>> T
On Sun, Sep 27, 2009 at 9:24 PM, Selena Deckelmann
wrote:
> Hi!
>
> On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh wrote:
>> On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
>>> Brad says:
>>>
>>> The patched code compiles without any additional warnings.
>>> Lint gripes ab
Hi!
On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh wrote:
> On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
>> Brad says:
>>
>> The patched code compiles without any additional warnings.
>> Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
>> print.h. Ot
On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
> Brad says:
>
>The patched code compiles without any additional warnings.
> Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
> print.h. Other additional lint seem to be false positives. The
> regressio
Hi!
Below is from Brad Slinger. I'm just forwarding his message so that
the review will be in the thread for the archives. (Sorry, Brad that I
missed this earlier.. I thought you'd already replied to the list for
some reason.)
Brad says:
Please forgive my top posting. Below is my patch review.
On Thu, Aug 27, 2009 at 10:17:32AM -0400, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>
> > > I initially left these exactly the same as for ASCII (the ':' and ';'
> > > usage). However, it's quite possible to make it use other characters.
> > > We could use the same lines, or two, three or
Alvaro Herrera escribió:
> > I initially left these exactly the same as for ASCII (the ':' and ';'
> > usage). However, it's quite possible to make it use other characters.
> > We could use the same lines, or two, three or four dashed lines
> > ('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
>
> Th
Roger Leigh escribió:
> On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
> > Roger Leigh escribió:
> >
> > > An updated copy of the patch is attached.
> >
> > Did you give expanded output a look? (\x) I find it a bit weird that
> > the first line shows a single-pixel wide line bu
On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
> Roger Leigh escribió:
>
> > An updated copy of the patch is attached.
>
> Did you give expanded output a look? (\x) I find it a bit weird that
> the first line shows a single-pixel wide line but the subsequent ones
> are thicker.
Roger Leigh escribió:
> An updated copy of the patch is attached.
I give it a try. It looks very reasonable. We could argue about the
exact chars to use but that can be changed later.
Did you give expanded output a look? (\x) I find it a bit weird that
the first line shows a single-pixel wid
On Sun, Aug 23, 2009 at 06:33:49PM -0400, Alvaro Herrera wrote:
> Roger Leigh escribió:
>
> > +#if (defined(HAVE_LANGINFO_H) && defined(CODESET))
> > + if (!strcmp(nl_langinfo(CODESET), "UTF-8"))
> > + text_format = &utf8format;
> > +#endif
>
> I think you should also try to match to
Roger Leigh escribió:
> +#if (defined(HAVE_LANGINFO_H) && defined(CODESET))
> + if (!strcmp(nl_langinfo(CODESET), "UTF-8"))
> + text_format = &utf8format;
> +#endif
I think you should also try to match to "UTF8", and do it in
case-insensitive manner (pg_strcasecmp), just like chkl
On Sun, Aug 23, 2009 at 01:49:02AM +0100, Roger Leigh wrote:
> On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> > On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > > Further minor cleanups to tweak column alignment in a corner case,
> > > and to correct indentation to match the
Greg Stark wrote:
I don't really have an opinion between one big patch versus multiple
smaller patches. That will come down to the code and whether the
separate patches are easier to read. It is sometimes hard to review a
patch when its separated from the code which needs the new
functionality
On Sun, Aug 23, 2009 at 1:49 AM, Roger Leigh wrote:
>> Please read the guidelines here:
>> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>>
>> I don't think it's very helpful to submit a patch intended to do
>> basically one thing split up over 10 threads. The PostgreSQL style is
>> heavyweig
On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > Further minor cleanups to tweak column alignment in a corner case,
> > and to correct indentation to match the rest of the code.
>
> Please read the guidelines here:
> http://wiki
On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> Further minor cleanups to tweak column alignment in a corner case,
> and to correct indentation to match the rest of the code.
Please read the guidelines here:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
I don't think it's very helpful
Further minor cleanups to tweak column alignment in a corner case,
and to correct indentation to match the rest of the code.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sou
Small followup patch to correct expanded=1 and border=0 output
as mentioned in previous email.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Pub
psql currently uses the ASCII characters '-' '|' and '+' to render
tables. However, most modern terminal emulators are capable of
displaying characters other than ASCII, including box drawing
characters which can be used to create rather more pleasing and
readable tables than ASCII punctuation can
96 matches
Mail list logo
