Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
What happened to this? I didn't see it applied.
I got puzzled by some delphic comments, and then I got pulled into work
of a higher priority, so it slipped down my list.
Maybe we can pick it up again in 9.
Andrew Dunstan wrote:
>
>
>
> Bruce Momjian wrote:
> > What happened to this? I didn't see it applied.
> >
> >
>
> I got puzzled by some delphic comments, and then I got pulled into work
> of a higher priority, so it slipped down my list.
>
> Maybe we can pick it up again in 9.1.
OK, sho
Bruce Momjian wrote:
What happened to this? I didn't see it applied.
I got puzzled by some delphic comments, and then I got pulled into work
of a higher priority, so it slipped down my list.
Maybe we can pick it up again in 9.1.
cheers
andrew
--
Sent via pgsql-hackers mailing list
What happened to this? I didn't see it applied.
---
Tom Lane wrote:
> Andrew Dunstan writes:
> > OK, and how are we going to set that flag? Like I did, with a separate
> > function?
>
> I would be inclined to invent a va
Tom Lane wrote:
I assume you are in effect saying you don't mind if there is an
occasional blank line in the output.
What blank line? I would expect prettyprinting of expressions to
sometimes insert an embedded newline, but not one at the beginning
or end. Do you have a counterexample?
Andrew Dunstan writes:
> OK, and how are we going to set that flag? Like I did, with a separate
> function?
I would be inclined to invent a variant of pg_get_viewdef with an
additional parameter rather than choosing a new function name, but
otherwise yeah. Or we could decide this isn't worth al
Tom Lane wrote:
Andrew Dunstan writes:
I am confused.
The original two line addition was already in effect driven by the
PRETTY_INDENT flag, because the appendContextKeyword call would be
effectively a no-op if that flag wasn't on. But apparently some people
don't want each c
Andrew Dunstan writes:
> I am confused.
> The original two line addition was already in effect driven by the
> PRETTY_INDENT flag, because the appendContextKeyword call would be
> effectively a no-op if that flag wasn't on. But apparently some people
> don't want each column on a separate lin
Tom Lane wrote:
Andrew Dunstan writes:
OK, drawing this together, what I did was to go back closer to my
original idea, but put this in a separate function, so nobody would get
too upset ;-)
This seems seriously ugly. Why don't you have the flag just driving
your original two-line
Andrew Dunstan writes:
> OK, drawing this together, what I did was to go back closer to my
> original idea, but put this in a separate function, so nobody would get
> too upset ;-)
This seems seriously ugly. Why don't you have the flag just driving
your original two-line addition?
Tom Lane wrote:
Greg Stark writes:
Incidentally I just tried
\d information_schema.views
and it *does* seem to put newlines after some of the target list
items. After each of the CASE expressions it puts a newline. So you
*already* get a mixture of some multiple items on a line
Greg Stark wrote:
On Thu, Aug 27, 2009 at 1:00 AM, Andrew Dunstan wrote:
Greg Stark wrote:
At least if it's all on one line
you can just not scroll to the right and see the rest of the query on
your screen.
This is where the confusion arises.
This is not possible on any termi
Greg Stark writes:
> Incidentally I just tried
> \d information_schema.views
> and it *does* seem to put newlines after some of the target list
> items. After each of the CASE expressions it puts a newline. So you
> *already* get a mixture of some multiple items on a line and some
> one-per-line.
On Thu, Aug 27, 2009 at 1:00 AM, Andrew Dunstan wrote:
> Greg Stark wrote:
>>
>> At least if it's all on one line
>> you can just not scroll to the right and see the rest of the query on
>> your screen.
>
> This is where the confusion arises.
>
> This is not possible on any terminal program I use -
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Well, let's see it? What do you do with expressions that don't fit?
See attached.
This isn't going to work as-is, because (a) buf->data can be moved
around by repalloc, and (b) you're not allowing for newline
Andrew Dunstan writes:
> Tom Lane wrote:
>> Well, let's see it? What do you do with expressions that don't fit?
> See attached.
This isn't going to work as-is, because (a) buf->data can be moved
around by repalloc, and (b) you're not allowing for newlines being
introduced within the column expr
Greg Stark wrote:
At least if it's all on one line
you can just not scroll to the right and see the rest of the query on
your screen.
This is where the confusion arises.
This is not possible on any terminal program I use - they don't scroll
left and right, they wrap, and the result in
On Wed, Aug 26, 2009 at 11:49 PM, Andrew Dunstan wrote:
> Maybe we need a couple of extra pg_get_viewdef() variants. One to wrap on
> some provided line length, one to wrap on every column. psql could use the
> first, pg_dump could use the second.
>
> I really can't believe anyone wants a single li
Tom Lane wrote:
Andrew Dunstan writes:
I do have a solution that wraps when running line length over 80 instead
of on every col:
SELECT sh.shoename, sh.sh_avail, sh.slcolor, sh.slminlen,
sh.slminlen * un.un_fact AS slminlen_cm, sh.slmaxlen,
sh.slmaxlen * un.un_fact AS s
Andrew Dunstan writes:
> I do have a solution that wraps when running line length over 80 instead
> of on every col:
> SELECT sh.shoename, sh.sh_avail, sh.slcolor, sh.slminlen,
> sh.slminlen * un.un_fact AS slminlen_cm, sh.slmaxlen,
> sh.slmaxlen * un.un_fact AS slmaxlen_cm, sh.slunit
>
Tom Lane wrote:
Greg Stark writes:
I agree with Tom's concerns -- think of that guy who was bumping up
against the 1600 column limit. At least if they're on one line you can
still see the structure of the query albeit with a very very wide
scrollbar...
But for typical queries I
Greg Stark writes:
> I agree with Tom's concerns -- think of that guy who was bumping up
> against the 1600 column limit. At least if they're on one line you can
> still see the structure of the query albeit with a very very wide
> scrollbar...
> But for typical queries I do agree one per line is
On Wed, Aug 26, 2009 at 7:47 PM, Andrew Dunstan wrote:
>> Did we kill the idea of trying to retain the original view definition?
>> Granted, that doesn't really help for SELECT *...
>
> That has nothing at all to do with the issue. The question is not about
> whether to keep the original, it's abou
decibel wrote:
On Aug 26, 2009, at 9:02 AM, Andrew Dunstan wrote:
The tiny patch attached fixes a long-standing peeve of mine (and at
least one of my clients'), namely that the target list printed in
viewdefs are unreadable.
example output now looks like this:
regression=# select pg_get
On Aug 26, 2009, at 9:02 AM, Andrew Dunstan wrote:
The tiny patch attached fixes a long-standing peeve of mine (and at
least one of my clients'), namely that the target list printed in
viewdefs are unreadable.
example output now looks like this:
regression=# select pg_get_viewdef('shoe',
Andreas Pflug escribió:
> When initially implementing the pretty option, I ran into the same
> consideration. Back then, I decided not to try any line breaking on the
> column list. Instead, I treated the columns as "just a bunch of
> columns", laying the emphasis on the from-clause (with potentia
Andrew Dunstan wrote:
>
>
>> But Pg
>> should have some pretty print function - it is easy implemented there.
>> Personally, I prefere Celko's notation, it is little bit more compact
>>
>> SELECT sh.shoename, sh.sh_avail, sh.slcolor, sh.slminlen,
>> sh.slminlen * un.un_fact AS slminl
Alvaro Herrera wrote:
Andrew Dunstan wrote:
[originally sent from wrong account :-( ]
Andrew, you can login to the majordomo site and set your secondary
address as an alias of this one. This means it'll recognize the other
address and allow you to post from there without going throu
Andrew Dunstan wrote:
>
> [originally sent from wrong account :-( ]
Andrew, you can login to the majordomo site and set your secondary
address as an alias of this one. This means it'll recognize the other
address and allow you to post from there without going through the
moderator queue. Of cou
Pavel Stehule wrote:
I am not sure - this should by task for client application.
pg_get_viewdef() already has a pretty print mode, and this change would
only affect output from that mode. Non-pretty printed output would be
unchanged.
My argument is that the pretty print mode for target l
2009/8/26 Andrew Dunstan :
>
> [originally sent from wrong account :-( ]
>
>
> The tiny patch attached fixes a long-standing peeve of mine (and at least
> one of my clients'), namely that the target list printed in viewdefs are
> unreadable.
>
> example output now looks like this:
>
> regression=
Andrew Dunstan writes:
> When you're dealing with a view that has 40 or 50 fields, having them
> all run together over a dozen or two lines is just horrible.
True, but is having them span a couple of screens vertically going to
be much better? There'll be a whole lot of wasted whitespace.
I'm
Tom Lane wrote:
Andrew Dunstan writes:
The tiny patch attached fixes a long-standing peeve of mine (and at
least one of my clients'), namely that the target list printed in
viewdefs are unreadable.
Personally I think this will take up enough vertical space to make
things less reada
Andrew Dunstan writes:
> The tiny patch attached fixes a long-standing peeve of mine (and at
> least one of my clients'), namely that the target list printed in
> viewdefs are unreadable.
Personally I think this will take up enough vertical space to make
things less readable on-screen, not more
34 matches
Mail list logo
