D'Arcy J.M. Cain wrote:
> On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
> Bruce Momjian wrote:
> > Yep, that is my analysis as well. If you want a pretty ReST-like
> > output, that can be added later.
>
> Not if you use "border 3" for full ReST. I see nothing but pushback
> later if you try to make
On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
Bruce Momjian wrote:
> Yep, that is my analysis as well. If you want a pretty ReST-like
> output, that can be added later.
Not if you use "border 3" for full ReST. I see nothing but pushback
later if you try to make "border 4" give less than "border 3."
Tom Lane wrote:
> Alvaro Herrera writes:
> > My vote goes for 1.
>
> > I wonder why you think it's impossible. Is it because you must scan
> > the whole table before being able to print any of it? (For example to
> > add extra alignment for the escaping backslashes in a way that doesn't
> > ren
On Mon, 12 Jan 2009, D'Arcy J.M. Cain wrote:
0. Drop this patch
1. Call it Rest and make it 100% compliant
2. Call it Rest-like
3. Call it simply border level 3
Every time I play with this for a minute or two, I'm able to find some
real-world data that completely breaks the ReST compatibility
On Mon, 12 Jan 2009, C?dric Villemain wrote:
we, at dalibo, used to write our docs with ReST and most of the time we
don't need to escape special char
I'm interested in this patch for a similar reason, ReST has been working
well for internal documentation at my office. I know I'll run into t
Alvaro Herrera writes:
> My vote goes for 1.
> I wonder why you think it's impossible. Is it because you must scan
> the whole table before being able to print any of it? (For example to
> add extra alignment for the escaping backslashes in a way that doesn't
> render it invalid.) Note that ps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D'Arcy J.M. Cain a écrit :
> So, what's happening. Is this discussion going into Limbo again for
> six months. It feels like the latest round of messages just went
> around the same circles as before. Let me summarize the different
> possibilities a
D'Arcy J.M. Cain wrote:
> So, what's happening. Is this discussion going into Limbo again for
> six months. It feels like the latest round of messages just went
> around the same circles as before. Let me summarize the different
> possibilities as I see them.
>
> 0. Drop this patch
> 1. Call it
So, what's happening. Is this discussion going into Limbo again for
six months. It feels like the latest round of messages just went
around the same circles as before. Let me summarize the different
possibilities as I see them.
0. Drop this patch
1. Call it Rest and make it 100% compliant
2. Ca
On Fri, 9 Jan 2009 22:46:06 -0500 (EST)
Greg Smith wrote:
> On Fri, 9 Jan 2009, D'Arcy J.M. Cain wrote:
>
> >> "." is on the long list of characters to be escaped I sent out earlier.
> >
> > I tried escaping the '.' but it didn't change the behaviour.
>
> I did try that specific exapmle in Trac
On Fri, 9 Jan 2009, D'Arcy J.M. Cain wrote:
"." is on the long list of characters to be escaped I sent out earlier.
I tried escaping the '.' but it didn't change the behaviour.
I did try that specific exapmle in Trac and it worked fine for me. Using
your test rig (which you gave the wrong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D'Arcy J.M. Cain a écrit :
>
> As Tom has pointed out, ReST has problems beyond our implementation.
> People who use it are aware of these warts. Given that I really think
> that the cleanest solution is to just give them "border 3", don't
> mention
On Thu, 8 Jan 2009 18:45:43 -0500 (EST)
Greg Smith wrote:
> >> A. Einstein was a really smart dude.
> > Which character in the above example would you escape.
>
> "." is on the long list of characters to be escaped I sent out earlier.
> The parser looks for all sorts of enumeration syntaxes--A.,
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
On Thu, 8 Jan 2009 13:51:44 -0500 (EST)
Greg Smith wrote:
A. Einstein was a really smart dude.
Which character in the above example would you escape.
"." is on the long list of characters to be escaped I sent out earlier.
The parser looks for al
D'Arcy J.M. Cain wrote:
> The problem with escaping is that someone may want this output for
> non-ReST purposes. They may not be making themselves known now but if
> we find a need later it will be hard if not impossible to make it
> available in a logical way. I would suggest that if we want a
On Thu, 8 Jan 2009 13:51:44 -0500 (EST)
Greg Smith wrote:
> A. Einstein was a really
> smart dude.
>
> Is parsed as two lines of text, while:
>
> A. Einstein was a really smart dude.
>
> Will be treated as a single-item list. That sort of ambiguity is quite a
Yes, this is an issue. I'm not
On Thu, 8 Jan 2009 13:05:03 -0500 (EST)
Bruce Momjian wrote:
> So what would this show?
>
> \*escape* \*escape*
>
> Want to bet the second word it italics.
Not in the Python implementation anyway. By the way, if you want to
try something, http://www.druid.net/darcy/rest.py.
--
D'Arcy J
On Thu, 2009-01-08 at 14:15 -0500, Michael Glaesemann wrote:
> On Jan 8, 2009, at 13:56 , Joshua D. Drake wrote:
>
> > There is interest in ReST for anyone doing a lot more than Python or
> > Trac. Although that area is certainly strong with it. It is quickly
> > becoming one of the more dominant
On Thu, 8 Jan 2009 14:15:26 -0500
Michael Glaesemann wrote:
> I think there may be confusion here betwixt ReST/RST and REST.
>
> REST: http://en.wikipedia.org/wiki/Representational_State_Transfer
> ReST/RST: http://en.wikipedia.org/wiki/ReStructuredText
Really? I don't think anyone in this conv
On Jan 8, 2009, at 13:56 , Joshua D. Drake wrote:
There is interest in ReST for anyone doing a lot more than Python or
Trac. Although that area is certainly strong with it. It is quickly
becoming one of the more dominant technologies in delivering web
services (now whether or not that is useful
"Joshua D. Drake" writes:
> There is interest in ReST for anyone doing a lot more than Python or
> Trac. Although that area is certainly strong with it. It is quickly
> becoming one of the more dominant technologies in delivering web
> services (now whether or not that is useful here is another ar
On Thu, 2009-01-08 at 13:44 -0500, Greg Smith wrote:
> On Thu, 8 Jan 2009, Tom Lane wrote:
>
> > Well, actually, I *still* don't see the value in being able to emit ReST
> > --- nobody except D'Arcy has stated an interest in the feature.
>
> I suggested interest in it and pointed out the popular
Greg Smith writes:
> After spending some time assembling a list of special characters, I had an
> ah-ha moment when I realized they are all listed in the "Sections" section
> as "section title adornment characters":
> ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
I'll give yo
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
Bruce Momjian wrote:
Right, so Tom says it isn't 100% ReST:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
Right but did you see the followup?
http://archives.postgresql.org/pgsql
On Thu, 8 Jan 2009, Tom Lane wrote:
Well, actually, I *still* don't see the value in being able to emit ReST
--- nobody except D'Arcy has stated an interest in the feature.
I suggested interest in it and pointed out the popularity of ReST for
anyone using Trac or Python, and Cedric Villemain
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
Some people suggests that this is so close to rst that I should just use
it as if it were, and hand-edit the output for the rare cases where it
doesn't comply. I don't find this very compelling.
The cases are so rare that I can't remember what they
Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, I did, and now I see why you said there might be only a few broken
> > cases. But I did not see any documentation in the standard saying that
> > was OK:
> > http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
>
> The example
Bruce Momjian writes:
> Yes, I did, and now I see why you said there might be only a few broken
> cases. But I did not see any documentation in the standard saying that
> was OK:
> http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
The example on that page is just bizarre
Tom Lane wrote:
> Alvaro Herrera writes:
> > People change their mind, or they forget the decision they took last
> > time and take the opposite one later. Tom said that he didn't see a
> > value in rst:
> > http://archives.postgresql.org/message-id/27079.1219365411%40sss.pgh.pa.us
>
> Well, act
"D'Arcy J.M. Cain" writes:
> On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
> Bruce Momjian wrote:
>> Right, so Tom says it isn't 100% ReST:
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
> Right but did you see the followup?
> http://archives.postgresql.org/pgsql-hackers/2008
D'Arcy J.M. Cain wrote:
> On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
> Bruce Momjian wrote:
> > Right, so Tom says it isn't 100% ReST:
> >
> > http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
>
> Right but did you see the followup?
>
> http://archives.postgresql.org/pgsql-hack
On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
Bruce Momjian wrote:
> Right, so Tom says it isn't 100% ReST:
>
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
Right but did you see the followup?
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01319.php
--
D'Arcy J.M
Alvaro Herrera writes:
> People change their mind, or they forget the decision they took last
> time and take the opposite one later. Tom said that he didn't see a
> value in rst:
> http://archives.postgresql.org/message-id/27079.1219365411%40sss.pgh.pa.us
Well, actually, I *still* don't see the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > D'Arcy J.M. Cain wrote:
>
> > > In fact I wrote it because I do want it for ReST. When I first
> > > proposed it that was my sell. I received pushback because it was for
> > > too specific a purpose so I stepped back and showed that it was simply
Bruce Momjian wrote:
> D'Arcy J.M. Cain wrote:
> > In fact I wrote it because I do want it for ReST. When I first
> > proposed it that was my sell. I received pushback because it was for
> > too specific a purpose so I stepped back and showed that it was simply
> > a logical extension that happe
C?dric Villemain wrote:
> Bruce Momjian a ?crit :
> > D'Arcy J.M. Cain wrote:
> >> On Thu, 8 Jan 2009 12:30:52 -0300
> >> Alvaro Herrera wrote:
> It is a great feature for people actually using ReST. However, the
> feature is really just a logical extension to the existing border
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian a écrit :
> D'Arcy J.M. Cain wrote:
>> On Thu, 8 Jan 2009 12:30:52 -0300
>> Alvaro Herrera wrote:
It is a great feature for people actually using ReST. However, the
feature is really just a logical extension to the existing bo
D'Arcy J.M. Cain wrote:
> On Thu, 8 Jan 2009 12:30:52 -0300
> Alvaro Herrera wrote:
> > > It is a great feature for people actually using ReST. However, the
> > > feature is really just a logical extension to the existing border
> > > attribute.
> >
> > Frankly I don't understand your position.
On Thu, 8 Jan 2009 12:30:52 -0300
Alvaro Herrera wrote:
> > It is a great feature for people actually using ReST. However, the
> > feature is really just a logical extension to the existing border
> > attribute.
>
> Frankly I don't understand your position. You seem to be saying that
> you want
Bruce Momjian writes:
> Well, did anyone say they actually liked the new format,
> appearance-wise, or would use it independently of ReST --- I don't
> remember anyone, and we don't want to extend the output format unless
> there is user demand.
Yeah. If it's not really ReST-compliant then the o
D'Arcy J.M. Cain wrote:
> On Wed, 07 Jan 2009 18:12:58 -0500
> Tom Lane wrote:
> > I think what Bruce meant to say is that this patch doesn't produce
> > 100% spec-compliant ReST, and that almost-ReST doesn't seem like a
> > good feature.
>
> It is a great feature for people actually using ReST.
D'Arcy J.M. Cain wrote:
> On Wed, 07 Jan 2009 18:12:58 -0500
> Tom Lane wrote:
> > "D'Arcy J.M. Cain" writes:
> > > Bruce Momjian wrote:
> > >> As I remember, no actual patch was posted for this.
> >
> > > There was. I am attaching it again in case there were any changes
> > > to original file
On Wed, 07 Jan 2009 18:12:58 -0500
Tom Lane wrote:
> "D'Arcy J.M. Cain" writes:
> > Bruce Momjian wrote:
> >> As I remember, no actual patch was posted for this.
>
> > There was. I am attaching it again in case there were any changes
> > to original files in the meantime.
>
> I think what Bru
D'Arcy J.M. Cain wrote:
> On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
> Bruce Momjian wrote:
> > D'Arcy J.M. Cain wrote:
> > > So what have we decided about this suggestion. Should I submit the
> > > patch or just forget about it? So far some people like it and some
> > > people think that it is unn
"D'Arcy J.M. Cain" writes:
> Bruce Momjian wrote:
>> As I remember, no actual patch was posted for this.
> There was. I am attaching it again in case there were any changes to
> original files in the meantime.
I think what Bruce meant to say is that this patch doesn't produce 100%
spec-complia
On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
Bruce Momjian wrote:
> D'Arcy J.M. Cain wrote:
> > So what have we decided about this suggestion. Should I submit the
> > patch or just forget about it? So far some people like it and some
> > people think that it is unneccessary. No one so far has sugges
D'Arcy J.M. Cain wrote:
> So what have we decided about this suggestion. Should I submit the
> patch or just forget about it? So far some people like it and some
> people think that it is unneccessary. No one so far has suggested that
> it would harm the system or people's use of it.
I have gon
D'Arcy J.M. Cain wrote:
> So what have we decided about this suggestion. Should I submit the
> patch or just forget about it? So far some people like it and some
> people think that it is unneccessary. No one so far has suggested that
> it would harm the system or people's use of it.
Has there
So what have we decided about this suggestion. Should I submit the
patch or just forget about it? So far some people like it and some
people think that it is unneccessary. No one so far has suggested that
it would harm the system or people's use of it.
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]>
Gregory Stark wrote:
> I wonder if it's worth keeping two variants at all really. Why not just make
> psql's native table formatting exactly ReST? Is there any part of it that we
> don't like as much as our existing tables?
It doubles the number of display lines; a very obvious shortcoming.
--
On Fri, 29 Aug 2008 18:07:36 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm starting to think D'Arcy's on the right track here.
Is that the train coming? :-)
> Keep in mind the use case here is as Alvaro says, just a user convenience
> thing. It's not meant for file dumps and loads. If we
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Joshua Drake escribió:
>
>> I am trying to understand why we are having a client do this? If you
>> want some other type of output, script it.
>
> Convenience. If we had real rst output, we could just copy'n paste into
> Trac or other systems.
I'm sta
Joshua Drake escribió:
> I am trying to understand why we are having a client do this? If you
> want some other type of output, script it.
Convenience. If we had real rst output, we could just copy'n paste into
Trac or other systems.
Convenience is why we have psql at all. Otherwise, surely ev
On Fri, 29 Aug 2008 11:23:50 -0500
"Jaime Casanova" <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 29, 2008 at 8:45 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]>
> wrote:
> >
> > I'm surprised that we don't have a general option to escape special
> > characters. Perhaps that's the next small enhancement.
>
On Fri, Aug 29, 2008 at 8:45 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
>
> I'm surprised that we don't have a general option to escape special
> characters. Perhaps that's the next small enhancement.
>
> darcy=# \pset escape \
>
this looks like we are trying to make cosmetic magic instead o
On Fri, 29 Aug 2008 06:55:45 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Aug 2008 01:29:14 -0400
> I think that your scan may have been a bit too cursory. Those
> characters, while significant in ReST, only matter when used in very
> specific ways. The following works just fi
On Fri, 29 Aug 2008 01:29:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm ... the patch works for data that contains no backslashes,
> asterisks, backquotes, vertical bars, nor underscores. Nor perhaps
> other special characters that I might've missed in one cursory scan of
> the ReST spec. I'
As stated above this format is mainly good for copy paste and may require
occasional manual tweaking.
Users should be people who use psql in their everyday work and on the other
hand need to publish data from database in some other places. Would you
please bring examples of some widespread applicat
Le Saturday 23 August 2008, D'Arcy J.M. Cain a écrit :
> On Thu, 21 Aug 2008 21:04:07 -0400
>
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > > There's still the question of whether this covers any needs that aren't
> > > met just as well by XML or CSV output formats.
> >
> > Well, we could rem
Le Friday 29 August 2008, Greg Smith a écrit :
> On Fri, 29 Aug 2008, Tom Lane wrote:
> > You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
> > It outputs something that might pass for ReST, but only so long as there
> > are no special characters in the data.
>
> I agree that
On Fri, 29 Aug 2008, Tom Lane wrote:
the patch works for data that contains no backslashes, asterisks,
backquotes, vertical bars, nor underscores.
These characters don't show up very much in real world data. You'll find
[-.,:;[EMAIL PROTECTED]&()"] in just about everything; those would be a
On Fri, 2008-08-29 at 01:29 -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Fri, 29 Aug 2008, Tom Lane wrote:
> >> You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
> >> It outputs something that might pass for ReST, but only so long as there
> >> are no
Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 29 Aug 2008, Tom Lane wrote:
>> You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
>> It outputs something that might pass for ReST, but only so long as there
>> are no special characters in the data.
> I'd hate to see a focus o
On Fri, 29 Aug 2008, Tom Lane wrote:
You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
It outputs something that might pass for ReST, but only so long as there
are no special characters in the data.
I agree that it's a bad idea to say explicitly that it's "ReST mode"
out
Greg Smith <[EMAIL PROTECTED]> writes:
> On Sat, 23 Aug 2008, Andrew Dunstan wrote:
>> I think we should probably confine ourselves to output formats that are in
>> very wide use or we'll be supporting a vast multitude. CSV and XML both
>> qualify here - not sure that ReST does.
> ReST is accept
On Sat, 23 Aug 2008, Andrew Dunstan wrote:
I think we should probably confine ourselves to output formats that are in
very wide use or we'll be supporting a vast multitude. CSV and XML both
qualify here - not sure that ReST does.
ReST is accepted by Trac, one of the more popular SCM+Project M
Steve Atkins <[EMAIL PROTECTED]> writes:
> On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote:
>> Personally I think it's rather nice to be able to have some extra
>> flexibility in how psql prints out data. Maybe, instead of the dry
>> and uninformative 'border 2', there could be a set of ouput co
On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote:
On Sun, Aug 24, 2008 at 2:00 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]>
wrote:
On Sat, 23 Aug 2008 14:57:50 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
Also, having now looked at the proposed patch, it seems clear that
it
isn't addressing the i
On Sun, 24 Aug 2008 13:22:38 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > I suppose it is my fault for mentioning ReST. That was the reason I
> > looked into this but that is not what the final proposal is.
>
> Well, if you can't just paste your output into ReST without having to
> hand-munge it
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Sat, 23 Aug 2008 14:57:50 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> So, quite aside from the question of whether we care to support ReST,
>> my opinion is that this patch fails to do so, and a significantly more
>> invasive patch would be nee
On Sun, 24 Aug 2008 09:16:43 -0400
"Merlin Moncure" <[EMAIL PROTECTED]> wrote:
> Personally I think it's rather nice to be able to have some extra
> flexibility in how psql prints out data. Maybe, instead of the dry
> and uninformative 'border 2', there could be a set of ouput control
> options.
On Sun, Aug 24, 2008 at 2:00 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
> On Sat, 23 Aug 2008 14:57:50 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Also, having now looked at the proposed patch, it seems clear that it
>> isn't addressing the issue of quoting/escaping at all; so I wonder how
On Sat, 2008-08-23 at 14:42 -0400, Andrew Dunstan wrote:
>
> D'Arcy J.M. Cain wrote:
> > On Thu, 21 Aug 2008 21:04:07 -0400
> > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> >
> >>> There's still the question of whether this covers any needs that aren't
> >>> met just as well by XML or CSV ou
On Sat, 23 Aug 2008 14:57:50 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, having now looked at the proposed patch, it seems clear that it
> isn't addressing the issue of quoting/escaping at all; so I wonder how
> this can be considered to be a safely machine-readable format.
It's not a machin
On Sat, 23 Aug 2008 14:42:57 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> In general I think I prefer machine readable formats to be produces by
> the backend so they are available through all clients, not just psql.
What do you mean by "machine readable?" XML?
> That said, this has suffic
D'Arcy J.M. Cain wrote:
On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
There's still the question of whether this covers any needs that aren't
met just as well by XML or CSV output formats.
Well, we could remove all the display formats except XML.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think we should probably confine ourselves to output formats that are
> in very wide use or we'll be supporting a vast multitude. CSV and XML
> both qualify here - not sure that ReST does.
Yeah, that's the core of my objection.
Also, having now loo
On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > There's still the question of whether this covers any needs that aren't
> > met just as well by XML or CSV output formats.
>
> Well, we could remove all the display formats except XML. After all,
> it can always
On Fri, 22 Aug 2008 08:23:01 +0200
Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote:
> > ReST is nice because it's almost plain text. In fact, a ReST document
> > source can easily be read raw.
>
> I presume by ReST you mean this
On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote:
> > I think it does -- I used to use the Latex output format for easy cut'n
> > pasting. ReST sounds like it serves the same purpose. If I had had to
> > use conversion to XML, it would have been rather painful.
>
> ReST is nice b
On Thu, 21 Aug 2008 21:19:58 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Tom Lane escribió:
> > There's still the question of whether this covers any needs that aren't
> > met just as well by XML or CSV output formats.
>
> I think it does -- I used to use the Latex output format for easy cut
Tom Lane escribió:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > On Thu, 21 Aug 2008 23:22:28 +0300
> > "Asko Oja" <[EMAIL PROTECTED]> wrote:
> >> The idea would be to use psql as backend for some other system?
> >> Or what do you mean by fed directly?
>
> > No, I meant that one would do an
On Thu, 21 Aug 2008 20:36:51 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > No, I meant that one would do any ad hoc query and cut and paste the
> > output directly into a tracking tool that supports ReST.
>
> There's still the question of whether th
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Thu, 21 Aug 2008 23:22:28 +0300
> "Asko Oja" <[EMAIL PROTECTED]> wrote:
>> The idea would be to use psql as backend for some other system?
>> Or what do you mean by fed directly?
> No, I meant that one would do any ad hoc query and cut and paste
On Thu, 21 Aug 2008 23:22:28 +0300
"Asko Oja" <[EMAIL PROTECTED]> wrote:
> The idea would be to use psql as backend for some other system?
> Or what do you mean by fed directly?
No, I meant that one would do any ad hoc query and cut and paste the
output directly into a tracking tool that supports
Proposed formats don't look easier to read for humans.
I doubt that they are more common or easier to process by machines than just
COPY query TO STDOUT CSV;
> The reason for this is to allow the output to be fed directly into any
> system using Restructured text
The idea would be to use psql as
On Thu, 21 Aug 2008 15:03:23 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I would like to propose a new border setting.
>
> That code is horrendously overcomplicated and unreadable already :-(
> I'm not too eager to add more variants to it.
Actual
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> I would like to propose a new border setting.
That code is horrendously overcomplicated and unreadable already :-(
I'm not too eager to add more variants to it.
> The reason for this is to allow the output to be fed directly into any
> system using
Here is a simple select output.
darcy=# select title_id, title_name from title;
title_id | title_name
--+
2 | Mrs
3 | Ms
4 | Miss
(3 rows)
Now I change the border.
darcy=# \pset border 2
Border style is 2.
darcy=# select title_id, title_name from tit
89 matches
Mail list logo
