Cliff Nieuwenhuis wrote:
> On Fri, 9 May 2008 08:38:01 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Bruce Momjian escribi?:
> > > Guillaume Smet wrote:
> > > > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]>
> > > > wrote:
> >
> > > > As I mentioned it before, is ther
On Fri, 9 May 2008 08:38:01 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Bruce Momjian escribió:
> > Guillaume Smet wrote:
> > > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]>
> > > wrote:
>
> > > As I mentioned it before, is there any chance for this fix to be
> > > backp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, 8.3 is already different from 8.2, and a lot of people will see
>> this particular aspect of it as a regression. I'm okay with
>> backpatching to 8.3 ... though the patch needed rather more testing
>> than you gave it.
> OK, so
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Guillaume Smet wrote:
> >> I understand your point of view but I really think it's more a
> >> regression fix than a behavior change.
>
> > If I can get other hackers to say we should backpatch we can consider
> > it.
>
> Well, 8.3 i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Guillaume Smet wrote:
>> I understand your point of view but I really think it's more a
>> regression fix than a behavior change.
> If I can get other hackers to say we should backpatch we can consider
> it.
Well, 8.3 is already different from 8.2, and
Bruce Momjian escribió:
> Guillaume Smet wrote:
> > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > As I mentioned it before, is there any chance for this fix to be
> > backported to 8.3 branch? IMHO it's a usability regression.
>
> No, we don't change behaviors in ba
Guillaume Smet wrote:
> On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > No, we don't change behaviors in back branches unless we get lots of
> > complaints, and we haven't in this case.
>
> I suspect it's annoying for a lot of people, just not annoying enough
> to make
On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> No, we don't change behaviors in back branches unless we get lots of
> complaints, and we haven't in this case.
I suspect it's annoying for a lot of people, just not annoying enough
to make them complain about it.
I unders
Guillaume Smet wrote:
> On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Applied.
>
> As I mentioned it before, is there any chance for this fix to be
> backported to 8.3 branch? IMHO it's a usability regression.
No, we don't change behaviors in back branches unles
On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Applied.
As I mentioned it before, is there any chance for this fix to be
backported to 8.3 branch? IMHO it's a usability regression.
Thanks.
--
Guillaume
--
Sent via pgsql-patches mailing list (pgsql-patches@postgre
Applied.
---
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> >
> > > > Surely psql computes the width of all cells before printing anything.
> > >
> > > It does, but if y
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on because you don't know the final width of the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on because you don't know the final width of the
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Surely psql computes the width of all cells before printing anything.
>
> It does, but if you have a value that has a tab, how do you know what
> tab stop you are on because you don't know the final width of the
> previous columns at that time, so
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > If you start counting every line from the start of the current column,
> > > it will align correctly regardless of the previous columns.
> >
> > At this stage you don't know the width of previous columns because you
>
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > If you start counting every line from the start of the current column,
> > it will align correctly regardless of the previous columns.
>
> At this stage you don't know the width of previous columns because you
> don't know if a very wide value is c
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Even if we knew the column position at output time, when we are doing
> > aligned column width computations, we don't know the width of the
> > previous columns so we would have no way to know how far the tab would
> > extend in the current column
Bruce Momjian wrote:
> Even if we knew the column position at output time, when we are doing
> aligned column width computations, we don't know the width of the
> previous columns so we would have no way to know how far the tab would
> extend in the current column.
If you start counting every lin
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have implemented the following patch which outputs tab as a tab. It
> > also assumes a tab has a width of 4, which is its average width:
>
> That pretty much completely sucks; it will undo all the hard work we've
> put into nice fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have implemented the following patch which outputs tab as a tab. It
> also assumes a tab has a width of 4, which is its average width:
That pretty much completely sucks; it will undo all the hard work we've
put into nice formatting of the output, beca
Cliff Nieuwenhuis wrote:
> On Tuesday 11 March 2008 11:41:35 Tom Lane wrote:
> > Cliff Nieuwenhuis <[EMAIL PROTECTED]> writes:
> > > I'm not sure how to ask this question. I have written a function, and
> > > with PostgreSQL 8.0.13 I can do a "\df+" and see something like this
> > > under Source C
21 matches
Mail list logo
