On 19.09.23 09:01, Peter Eisentraut wrote:
While testing this, I noticed that the way the check_clause of regular
check constraints is computed appears to be suboptimal. It currently does
CAST(substring(pg_get_constraintdef(con.oid) from 7) AS character_data)
which ends up with an extra set
On 14.09.23 10:20, Peter Eisentraut wrote:
On 06.09.23 19:52, Alvaro Herrera wrote:
+ SELECT current_database()::information_schema.sql_identifier AS
constraint_catalog,
+ rs.nspname::information_schema.sql_identifier AS
constraint_schema,
+
On 2023-Sep-18, Peter Eisentraut wrote:
> On 14.09.23 10:20, Peter Eisentraut wrote:
> > Small correction here: This should be
> >
> > pg_catalog.format('%s IS NOT NULL',
> > at.attname)::information_schema.character_data AS check_clause
> >
> > That is, the word "CHECK" and the parentheses
On 14.09.23 10:20, Peter Eisentraut wrote:
On 06.09.23 19:52, Alvaro Herrera wrote:
+ SELECT current_database()::information_schema.sql_identifier AS
constraint_catalog,
+ rs.nspname::information_schema.sql_identifier AS
constraint_schema,
+
On 06.09.23 19:52, Alvaro Herrera wrote:
+SELECT current_database()::information_schema.sql_identifier AS
constraint_catalog,
+ rs.nspname::information_schema.sql_identifier AS constraint_schema,
+ con.conname::information_schema.sql_identifier AS constraint_name,
+
On 2023-Sep-06, Alvaro Herrera wrote:
> On 2023-Sep-04, Alvaro Herrera wrote:
>
> > In reference to [1], 0001 attached to this email contains the updated
> > view definitions that I propose.
>
> Given the downthread discussion, I propose the attached. There are no
> changes to v2, other than
On 9/6/23 05:40, Tom Lane wrote:
Vik Fearing writes:
On 9/6/23 02:53, Tom Lane wrote:
What solution do you propose? Starting to enforce the spec's rather
arbitrary requirement that constraint names be unique per-schema is
a complete nonstarter. Changing the set of columns in a spec-defined
3] Update information_schema definition for not-null
constraints
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Now that we have catalogued not-null constraints, our information_schema
definition must be updated to grab those rather than fabricate synthetic
de
On 05.09.23 18:24, Alvaro Herrera wrote:
On 2023-Sep-05, Peter Eisentraut wrote:
The following information schema views are affected by the not-null
constraint catalog entries:
1. CHECK_CONSTRAINTS
2. CONSTRAINT_COLUMN_USAGE
3. DOMAIN_CONSTRAINTS
4. TABLE_CONSTRAINTS
Note that 1 and 3 also
Vik Fearing writes:
> On 9/6/23 02:53, Tom Lane wrote:
>> What solution do you propose? Starting to enforce the spec's rather
>> arbitrary requirement that constraint names be unique per-schema is
>> a complete nonstarter. Changing the set of columns in a spec-defined
>> view is also a
On 9/6/23 02:53, Tom Lane wrote:
Vik Fearing writes:
On 9/6/23 00:14, David G. Johnston wrote:
I'm not all that for either A or B since the status quo seems workable.
Pray tell, how is it workable? The view does not identify a specific
constraint because we don't obey the rules on one
Vik Fearing writes:
> On 9/6/23 00:14, David G. Johnston wrote:
>> I'm not all that for either A or B since the status quo seems workable.
> Pray tell, how is it workable? The view does not identify a specific
> constraint because we don't obey the rules on one side and we do obey
> the rules
On 9/6/23 00:14, David G. Johnston wrote:
I'm not all that for either A or B since the status quo seems workable.
Pray tell, how is it workable? The view does not identify a specific
constraint because we don't obey the rules on one side and we do obey
the rules on the other side. It is
On Tue, Sep 5, 2023 at 2:50 PM Vik Fearing wrote:
> On 9/5/23 19:15, Alvaro Herrera wrote:
> > On 2023-Sep-05, Alvaro Herrera wrote:
> >
> > Looking now at what to do for CHECK_CONSTRAINTS with domain constraints,
> > I admit I'm completely confused about what this view is supposed to
> > show.
On 9/5/23 19:15, Alvaro Herrera wrote:
On 2023-Sep-05, Alvaro Herrera wrote:
Looking now at what to do for CHECK_CONSTRAINTS with domain constraints,
I admit I'm completely confused about what this view is supposed to
show. Currently, we show the constraint name and a definition like
"CHECK
On 2023-Sep-05, Alvaro Herrera wrote:
> After looking at what happens for domain constraints in older versions
> (I tested 15, but I suppose this applies everywhere), I notice that we
> don't seem to handle them anywhere that I can see. My quick exercise is
> just
>
> create domain nnint as int
On 2023-Sep-05, Peter Eisentraut wrote:
> The following information schema views are affected by the not-null
> constraint catalog entries:
>
> 1. CHECK_CONSTRAINTS
> 2. CONSTRAINT_COLUMN_USAGE
> 3. DOMAIN_CONSTRAINTS
> 4. TABLE_CONSTRAINTS
>
> Note that 1 and 3 also contain domain constraints.
Alvaro Herrera writes:
> In 0002, I took the tests added by Peter's proposed patch and put them
> in a separate test file that runs at the end. There are some issues,
> however. One is that the ORDER BY clause in the check_constraints view
> is not fully deterministic, because the table name is
In reference to [1], 0001 attached to this email contains the updated
view definitions that I propose.
In 0002, I took the tests added by Peter's proposed patch and put them
in a separate test file that runs at the end. There are some issues,
however. One is that the ORDER BY clause in the
19 matches
Mail list logo
