Tom Lane wrote:
> I think if we change it here we will also have to revisit hundreds of
> places in the backend, such as this one:
> regression=# select * from public.bar;
> ERROR: relation "public.bar" does not exist
> and indeed the whole question of what we are using quotes for in
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So it seems we can either go with no quotes, or smart quotes (which my
> > patch implemented). I feel my patch does the best of both worlds, by
> > quoting as needed, and as the psql \d commands actually require anyway,
> > and as us
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So it seems we can either go with no quotes, or smart quotes (which my
> patch implemented). I feel my patch does the best of both worlds, by
> quoting as needed, and as the psql \d commands actually require anyway,
> and as used by pg_dump and in SQL q
Tom Lane wrote:
> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne writes:
> >> Now you've lost me - how is a user-inputted object name translatable?
>
> > Not all languages use "..." as quote symbols, but if you make them part of
> > some string that comes from the backe
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne writes:
>> Now you've lost me - how is a user-inputted object name translatable?
> Not all languages use "..." as quote symbols, but if you make them part of
> some string that comes from the backend, it becomes prohibitively
Bruce Momjian writes:
> I see pg_dump using the same rules that I am proposing:
Which makes my point.
> To me quoting the table name is like quoting the name of a section
> heading (which people don't do),
The message style guidelines specify that you should always quote a %s if
it might contain
Tom Lane writes:
> As Bruce pointed out, this isn't really a message; it's just a column
> heading, and so it's not clear that the message style guidelines apply.
How is this different? Just because text is in a box or formatted in a
particular way, it doesn't change the nature of the content.
Christopher Kings-Lynne writes:
>>>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-inpu
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
--
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 i
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
"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 before we devi
Christopher Kings-Lynne writes:
> 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.
---(end of broadcast)
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 someth
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 consumptio
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) 3
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
+-+-
"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 prod
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
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
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
su
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() to double-quot
22 matches
Mail list logo
