Bruce Momjian writes:
psql \d always double-quotes table names:
Yes, and that is conforming to message style rules. Please leave it at that.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Peter Eisentraut wrote:
Bruce Momjian writes:
psql \d always double-quotes table names:
Yes, and that is conforming to message style rules. Please leave it at that.
But it isn't a message:
Table public.xx
Column | Type | Modifiers
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
psql \d always double-quotes table names:
Table public.xx
Yeah, that has bugged me for a while, because it is in fact *wrong* ...
the above representation of a qualified name is incorrect.
This patch uses pg_dump fmtId()
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
psql \d always double-quotes table names:
Yes, and that is conforming to message style rules. Please leave it at that.
The problem is that it is double-quoting a qualified name, which is
something we generally don't produce in
initPQExpBuffer(buf);
printfPQExpBuffer(buf,
! SELECT n.nspname AS \%s\,\n
! u.usename AS \%s\\n
FROM pg_catalog.pg_namespace n LEFT JOIN pg_catalog.pg_user u\n
! ON n.nspowner=u.usesysid\n
!
Hey Bruce,
While you're at it - use the same sort of code to conditionally quote
index, rule and constraint names ...
Chris
Bruce Momjian wrote:
psql \d always double-quotes table names:
Table public.xx
Column | Type | Modifiers
Christopher Kings-Lynne wrote:
Hey Bruce,
While you're at it - use the same sort of code to conditionally quote
index, rule and constraint names ...
Those are in the patch.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
Bruce Momjian writes:
But it isn't a message:
Table public.xx
Column | Type | Modifiers
+-+---
y | integer |
Indexes:
ii btree (y)
By definition, everything that is printed out for human consumption is a
Tom Lane writes:
The problem is that it is double-quoting a qualified name, which is
something we generally don't produce in messages. I think it's actively
misleading.
While I don't really agree that this is a problem, better solutions would
be to not quote the thing at all or write
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
While I don't really agree that this is a problem, better solutions would
be to not quote the thing at all or write something like Table %s
(Schema %s). However, the message style guidelines are very clear on
this point, and
Peter Eisentraut wrote:
Bruce Momjian writes:
But it isn't a message:
Table public.xx
Column | Type | Modifiers
+-+---
y | integer |
Indexes:
ii btree (y)
By definition, everything that is printed out for
I have applied this patch to suppress non-local temp schemas from psql
\dn.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
ViSolve Open Source Team [EMAIL PROTECTED] writes:
this is a modified and more focussed patch request for PostgreSQL for for H=
P-UX
11i V2 for the Intel Itanium architecture (known to the PostgreSQL code as
IA-64).=20
I looked into applying the TAS part of this patch now that Bruce has
Not that this is incorrect. You need to go:
LIKE 'pg_temp_%' probably.
Got it.
Yes. Sigh. It's so annoying living about 15 hours out from when all
this stuff happens :P
I read a thread, come across something, and then make a contribution,
only to read about 40 threads down that the
While you're at it - use the same sort of code to conditionally quote
index, rule and constraint names ...
That makes you part of the problem, because these sections are impossible
to translate correctly.
Now you've lost me - how is a user-inputted object name translatable?
Chris
To go in src/port/ directory.
This is to allow the handles returned by pipe to be used in select() calls
(which Win32 doesn't allow with the native pipe() call), thereby obviating
the need for reworking of the select() mechanisms in pgstat.c.
Additionally, something of the sort would be
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not that hard ... just requires replacing some special-purpose code with
general-purpose code ...
Does that code cause the variables value to change from function call to
function call (what most users would expect if they give it a
17 matches
Mail list logo
