Excerpts from Joe Abbate's message of mié nov 30 02:15:09 -0300 2011:
Thanks Tom and Robert. I think I understand the problem now. I guess
I'll have to work around this quirk by dealing specially with type
names and not quote them when they're in the shorter list of SQL
Standard reserved
On 11/30/2011 09:02 AM, Alvaro Herrera wrote:
Excerpts from Joe Abbate's message of mié nov 30 02:15:09 -0300 2011:
Thanks Tom and Robert. I think I understand the problem now. I guess
I'll have to work around this quirk by dealing specially with type
names and not quote them when they're
Andrew Dunstan and...@dunslane.net writes:
On 11/30/2011 09:02 AM, Alvaro Herrera wrote:
I wonder if it would simpler to just not quote type names except when
absolutely necessary.
Yeah, and very much less ugly. Ploughing through masses of unnecessary
quotes is they way to a headache.
On 11/30/2011 09:55 AM, Tom Lane wrote:
One possible solution, if you're getting type information about columns
from the server, is to cast the type OID to regtype and let the regtype
output converter make all the decisions. It's less notation than a join
to pg_type anyway.
Unfortunately,
Joe Abbate j...@freedomcircle.com wrote:
On 11/30/2011 09:55 AM, Tom Lane wrote:
One possible solution, if you're getting type information about
columns from the server, is to cast the type OID to regtype and
let the regtype output converter make all the decisions. It's
less notation than a
On 11/30/2011 11:26 AM, Kevin Grittner wrote:
You are prepared to handle the difference between char and char, I
hope.
We have not implemented a type verifier in Pyrseas. It currently
generates SQL based on the type given in the input. In normal usage,
dbtoyaml is expected to be invoked
Joe Abbate j...@freedomcircle.com wrote:
On 11/30/2011 11:26 AM, Kevin Grittner wrote:
You are prepared to handle the difference between char and
char, I hope.
Pyrseas depends on the ultimate type verifier: the
PostgreSQL parser (and related routines).
OK. I just wanted to be sure that
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to quote the TYPE. Can someone
please
On 11/29/2011 10:09 PM, Robert Haas wrote:
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable to
On Tue, Nov 29, 2011 at 11:21 PM, Joe Abbate j...@freedomcircle.com wrote:
Why does it allow quoting of integer as the table name and the column
name, but not as the type name? Furthermore,
Because there's nothing called integer in the pg_type catalog. It's
not really a type name; as Tom
On 11/29/2011 11:41 PM, Tom Lane wrote:
Another way to say that is that the type int4 can be specified in two
ways:
int4(an identifier)
INTEGER (a keyword)
Quoting int4 is no problem, because it's still an identifier, but
quoting integer takes away its
Robert Haas robertmh...@gmail.com writes:
I will cheerfully admit that this is confusing and inconvenient, and I
didn't understand it either until I implemented pg_dump
--quote-all-identifiers. However, I'm not sure there's any easy way
to improve the situation.
... especially without
13 matches
Mail list logo
