An alternative might be something that postprocesses the output from
pg_dump into, say, XML. I've been thinking about that. I might put it
on my todo list.
andrew
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
It just seemed complex to figure out which operators needed parens an
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >It might be a bit risky getting pg_dump to use it though?
> >
> >
> >
> >I don't think we every want pg_dump to use it --- better accurate than
> >pretty in there.
> >
> Agreed.
>
> > There seems to be some tough assumptions that have to
> >be m
Christopher Kings-Lynne wrote:
> Hi guys (tom),
>
> Just reminding people that there was a question regarding my changes to
> psql's \d command. I'm not sure if everyone wanted all the identifier
> names double quoted or not...
I assume we don't want them always quoted.
> And are people happy w
Bruce Momjian wrote:
Still, if there's something not precise, it should be cleared. Which
tough assumptions are made that seem doubtful to you?
It just seemed complex to figure out which operators needed parens and
which didn't.
Only very-well-documented operators (Chapter 4.1.6) a
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > It might be a bit risky getting pg_dump to use it though?
>
> I definitely don't want pg_dump using the pretty-print stuff ;-).
> I'm neutral on whether to use it in psql's \d commands.
I thought the pretty-printing stuff w
> I assume we don't want them always quoted.
Problem with that is that someone has to move the to-quote-or-not function
from pg_dump into psql...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
> could be \dn for describe namespace for ei : \dn pg_catalog,
> or only \dn to list all namespaces
Already done in CVS...
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Only very-well-documented operators (Chapter 4.1.6) are parens-optimized
(+-*/%);
At the moment ... but you can be sure there will be demand to get smarter.
I never claimed to implement the ultimate solution, just wanted t
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Only very-well-documented operators (Chapter 4.1.6) are parens-optimized
> (+-*/%);
At the moment ... but you can be sure there will be demand to get
smarter.
regards, tom lane
---(end of broadcast)-
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
It just seemed complex to figure out which operators needed parens and
which didn't.
The fact that the first attempt was wrong doesn't improve my faith in
that code one bit ;-).
It was posted expressiv
could be \dn for describe namespace for ei : \dn pg_catalog,
or only \dn to list all namespaces
?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Christopher Kings-Lynne wrote:
> > I assume we don't want them always quoted.
>
> Problem with that is that someone has to move the to-quote-or-not function
> from pg_dump into psql...
Attached is a psql/Makefile patch that makes fmtId() available to psql C
code.
I tried a test and it seemed to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It just seemed complex to figure out which operators needed parens and
> which didn't.
The fact that the first attempt was wrong doesn't improve my faith in
that code one bit ;-). I don't want pg_dump invoking it, even as an
option. Someone will get bu
Added to TODO:
* Prevent unneeded quoting in psql \d output using fmtId()
---
Christopher Kings-Lynne wrote:
> > I assume we don't want them always quoted.
>
> Problem with that is that someone has to move the to-
On Fri, Aug 08, 2003 at 09:17:05AM +0800, Christopher Kings-Lynne wrote:
> australia=# \d affiliates_transactions
> View "public.affiliates_transactions"
[...]
> View definition:
> SELECT palm_buyers.affiliate_id, timestamptz(abstime(palm_buyers.datetime))
> AS
> date, 'Palm' AS "type", 1
Bruce Momjian wrote:
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
It might be a bit risky getting pg_dump to use it though?
I definitely don't want pg_dump using the pretty-print stuff ;-).
I'm neutral on whether to use it in psql's \d commands.
I thought
Bruce Momjian wrote:
It might be a bit risky getting pg_dump to use it though?
I don't think we every want pg_dump to use it --- better accurate than
pretty in there.
Agreed.
There seems to be some tough assumptions that have to
be made in that function that are better used for visual-only c
Well for me it's the difference between this:
australia=# \d affiliates_transactions
View "public.affiliates_transactions"
Column| Type | Modifiers
--+--+---
affiliate_id | integer |
date | t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> It might be a bit risky getting pg_dump to use it though?
I definitely don't want pg_dump using the pretty-print stuff ;-).
I'm neutral on whether to use it in psql's \d commands.
regards, tom lane
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It just seemed complex to figure out which operators needed parens and
> > which didn't.
>
> The fact that the first attempt was wrong doesn't improve my faith in
> that code one bit ;-). I don't want pg_dump invoking it, even as an
Hi guys (tom),
Just reminding people that there was a question regarding my changes to
psql's \d command. I'm not sure if everyone wanted all the identifier
names double quoted or not...
And are people happy with the layout in general? Also, I think it'd be
nice if my recent patch to use the ne
21 matches
Mail list logo
