Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> We could check the first character of the definition, and if it isn't a
> left parenthesis, then we add parentheses.
And we would be wrong. Consider
(a < 0) and (b > 0)
regards, tom lane
-
True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of parentheses for CHECK constraints?
No, but it will require some restructuring of the code to get rid of it
safely (where "safely" is defined as "never omitting any parentheses
that *are* necessary").
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> True. Btw., is there a particular value in pg_get_constraintdef always
> printing double pairs of parentheses for CHECK constraints?
No, but it will require some restructuring of the code to get rid of it
safely (where "safely" is defined as "never o
Tom Lane writes:
> The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function
> rather than consrc, for the same reasons as psql should (I haven't fixed
> the latter yet, but will soon).
True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of pa
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I notice that most of the references in the information_schema.sql are
>> not schema-qualfied.
> They don't need to be, because the references will be resolved when the
> views are parsed during initdb.
On second thought, you do have a poi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I notice that most of the references in the information_schema.sql are
> not schema-qualfied.
They don't need to be, because the references will be resolved when the
views are parsed during initdb.
regards, tom lane
-
I looked through all the information_schema stuff, and found a few more
nits.
I notice that most of the references in the information_schema.sql are
not schema-qualfied.
eg:
FROM (pg_namespace ncon INNER JOIN pg_constraint con ON ncon.oid
Shouldn't that be:
FROM (pg_catalog.pg_namespace ncon I
I looked through all the information_schema stuff, and found a few more
nits.
The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function
rather than consrc, for the same reasons as psql should (I haven't fixed
the latter yet, but will soon).
There are several views that display pg_type
