Joe Abbate 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 you were aware
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 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 join to pg_typ
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,
Andrew Dunstan 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. quote_ident() gets
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
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 reser
Robert Haas 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 breaking compatibility w
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 a
On Tue, Nov 29, 2011 at 11:21 PM, Joe Abbate 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 says, it's some rando
Robert Haas writes:
> On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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
>> pleas
On 11/29/2011 10:09 PM, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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.
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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 explain why that is not t
13 matches
Mail list logo
