On Wed, 15 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > The main options seem to be:
> > When we're allowing other order access, immediately reorder the
> > constraint information to match the primary key order. This helps out
> > with IS since the loaded constraint
Stephan Szabo <[EMAIL PROTECTED]> writes:
> The main options seem to be:
> When we're allowing other order access, immediately reorder the
> constraint information to match the primary key order. This helps out
> with IS since the loaded constraint should display properly, but
> theoretically cou
On Wed, 15 Mar 2006, Clark C. Evans wrote:
> On Tue, Mar 14, 2006 at 11:11:29PM -0800, Stephan Szabo wrote:
> | When we're allowing other order access, immediately reorder the
> | constraint information to match the primary key order.
>
> Let me try to parrot. In PostgreSQL, the pairing informati
On Tue, Mar 14, 2006 at 11:11:29PM -0800, Stephan Szabo wrote:
| When we're allowing other order access, immediately reorder the
| constraint information to match the primary key order.
Let me try to parrot. In PostgreSQL, the pairing information between
the foreign-key and unique-key constraint
On Wed, 15 Mar 2006, Clark C. Evans wrote:
> On Tue, Mar 14, 2006 at 10:01:16PM -0800, Stephan Szabo wrote:
> | The point is that because rows in a table don't have order (unless
> | information_schema has special rules) the two constraints above seem to
> | look the same to me in their represent
On Tue, Mar 14, 2006 at 10:01:16PM -0800, Stephan Szabo wrote:
| The point is that because rows in a table don't have order (unless
| information_schema has special rules) the two constraints above seem to
| look the same to me in their representation in
| information_schema.constraint_column_usage
On Tue, 14 Mar 2006, Stephan Szabo wrote:
> We need to offer this for spec complience reasons, but I don't think it
> actually fixes the problem you would have with information_schema.
Which of course is wrong, as i figured out when the discussion came up the
first time and forgot when I came to
On Wed, 15 Mar 2006, Clark C. Evans wrote:
> On Tue, Mar 14, 2006 at 08:14:12PM -0800, Stephan Szabo wrote:
> | > CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
> | > CREATE TABLE a (b text, c text);
> | > ALTER TABLE a ADD FOREIGN KEY (b, c) REFERENCES x(z, y);
> ...
> | > I asser
On Tue, Mar 14, 2006 at 08:14:12PM -0800, Stephan Szabo wrote:
| > CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| > CREATE TABLE a (b text, c text);
| > ALTER TABLE a ADD FOREIGN KEY (b, c) REFERENCES x(z, y);
...
| > I assert the problem here is that the FOREIGN KEY constraint
|
[Resurrecting an old thread]
On Sat, 25 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> | > > * for foreign-key and check constraints, the default names
> | > > are $1, $2, etc.; it would be great if they were "upgraded"
> | > > to use
On Mon, Feb 27, 2006 at 02:17:03PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> > Yes, I agree with him on that. However, there's a certain amount of
> > confusion inspired by the organization that: "If you want to look up the
> > table's columns go to information_schmea, if you want the tabl
On Mon, Feb 27, 2006 at 11:24:05AM -0800, Josh Berkus wrote:
> Andrew,
>
> >How fine-grained do we want to get on namespaces? I'd be slightly more
> >inclined to have pg_info or maybe pg_utils as a place to stash not only
> >extra system views but other utility stuff that we want to ship but is
Andrew,
How fine-grained do we want to get on namespaces? I'd be slightly more
inclined to have pg_info or maybe pg_utils as a place to stash not only
extra system views but other utility stuff that we want to ship but is
essentially droppable.
AFAIK, none of the contributors to newsysviews
Andrew - Supernews wrote:
On 2006-02-27, Tom Lane <[EMAIL PROTECTED]> wrote:
I do have doubts about adding any large number of add-on views to
pg_catalog, because of the privileged place of that schema in search
paths. It'd be better to put them in a separate schema ("pg_info"
maybe?) whe
Josh Berkus writes:
> Yes, I agree with him on that. However, there's a certain amount of
> confusion inspired by the organization that: "If you want to look up the
> table's columns go to information_schmea, if you want the table *size*
> go to sysviews." But maybe that's unavoidable. Or ma
Tom,
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the information_schema (like aggregates) because we can't modify it in any
way. But per Peter we can't add new views to the pg_catalog because we
want people to use information_schema. I sense a catch-22 here.
On 2006-02-27, Tom Lane <[EMAIL PROTECTED]> wrote:
> I do have doubts about adding any large number of add-on views to
> pg_catalog, because of the privileged place of that schema in search
> paths. It'd be better to put them in a separate schema ("pg_info"
> maybe?) where they'd pose less risk of
On Mon, Feb 27, 2006 at 11:39:30AM -0500, Tom Lane wrote:
| Josh Berkus writes:
| >> No way. The entire point of information_schema is that it is standard;
| >> adding non-spec things to it renders it no better than direct access
| >> to the PG catalogs.
| >
| > Hmmm ... so, per you, we can't add
Josh Berkus writes:
>> No way. The entire point of information_schema is that it is standard;
>> adding non-spec things to it renders it no better than direct access
>> to the PG catalogs.
> Hmmm ... so, per you, we can't add extra views covering non-spec objects to
> the information_schema (li
Tom,
> No way. The entire point of information_schema is that it is standard;
> adding non-spec things to it renders it no better than direct access
> to the PG catalogs.
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the information_schema (like aggregates) because
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
> | > * Issue a warning when creating a constraint who's name is
> | > not unique within its (the constraint's) schema.
> |
> | I don't have a problem with it (once, I argued for fol
Clark C. Evans wrote:
| > * Issue a warning when creating a constraint who's name is
| > not unique within its (the constraint's) schema.
|
| I don't have a problem with it (once, I argued for following the spec
| constraint on this way back when), however I think this was proposed an
On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
| > * Forbidding the creation of a foreign key constraint where
| > the column list for the referenced table doesn't *exactly*
| > match a canidate key on that table.
|
| About the best we're likely to be able to do is change
Josh Berkus writes:
> 2) Modify the newsysviews to be extensions of the information_schema views:
> e.g. information_schema.tables would have the SQL03 information, and
> information_schema.tables_pg would have pg-specific stuff like table
> size
> and last analyzed date.
No way.
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 04:50:41PM -0500, Rod Taylor wrote:
> On Sat, Feb 25, 2006 at 02:01:00PM -0800, Stephan Szabo wrote:
> | > On Sat, 25 Feb 2006, Clark C. Evans wrote:
> | > >
> | > > CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
> | > >
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> Stephen,
>
> So, a quick re-cap of the questions/concerns I had:
>
> * Making the default constraint names include the table
>
> -> This was implemented in 8.x, thank you!
>
> * Forbidding the creation of a foreign key constraint where
> th
Stephen,
So, a quick re-cap of the questions/concerns I had:
* Making the default constraint names include the table
-> This was implemented in 8.x, thank you!
* Forbidding the creation of a foreign key constraint where
the column list for the referenced table doesn't *exactly*
On Sat, Feb 25, 2006 at 04:50:41PM -0500, Rod Taylor wrote:
| Can out point it out in the below psql output?
|
| k=# CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "x_pkey"
| for table "x"
| CREATE TABLE
| k=# CREATE TABL
Guys,
So, based on this discussion, I'd like to consider taking a second stab at
newsysviews:
1) Implement SQL03 changes into the information_schema, using some of the
code from newsysviews;
2) Modify the newsysviews to be extensions of the information_schema views:
e.g. information_sc
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> Bruno,
>
> > This has been discussed previously in a couple of threads. I believe the
> > desire is to make it work as specified in SQL-2003, but I do not remember
> > whether or not anyone volunteered to do the work to make it happen.
On Sat, 25 Feb 2006, Stephan Szabo wrote:
>
> On Sat, 25 Feb 2006, Clark C. Evans wrote:
>
> > On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> > | > > * for foreign-key and check constraints, the default names
> > | > > are $1, $2, etc.; it would be great if they were "upgra
On Sat, 25 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> | > > * for foreign-key and check constraints, the default names
> | > > are $1, $2, etc.; it would be great if they were "upgraded"
> | > > to use the default names given by pr
On Sat, 2006-02-25 at 16:35 -0500, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> | > > * for foreign-key and check constraints, the default names
> | > > are $1, $2, etc.; it would be great if they were "upgraded"
> | > > to use the default names
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| > > * for foreign-key and check constraints, the default names
| > > are $1, $2, etc.; it would be great if they were "upgraded"
| > > to use the default names given by primary and unique key
| > > constraints: table_uk
On Sat, 25 Feb 2006, Stephan Szabo wrote:
>
> On Sat, 25 Feb 2006, Clark C. Evans wrote:
>
> > On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> > | > This has been discussed previously in a couple of threads. I believe the
> > | > desire is to make it work as specified in SQL-2003,
On Sat, 25 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> | > This has been discussed previously in a couple of threads. I believe the
> | > desire is to make it work as specified in SQL-2003, but I do not remember
> | > whether or not anyone volu
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
| > This has been discussed previously in a couple of threads. I believe the
| > desire is to make it work as specified in SQL-2003, but I do not remember
| > whether or not anyone volunteered to do the work to make it happen.
|
| I beli
Bruno,
> This has been discussed previously in a couple of threads. I believe the
> desire is to make it work as specified in SQL-2003, but I do not remember
> whether or not anyone volunteered to do the work to make it happen.
I believe that the newsysviews follow the SQL03 permissions structure
On Fri, Feb 24, 2006 at 19:40:33 -0500,
"Clark C. Evans" <[EMAIL PROTECTED]> wrote:
>
> While the textual description of this view "Identify domain constraints
> in this catalog accessable to a given user." has not changed between
> SQL-1992 and SQL-2003, the actual critera specified is quite di
On Fri, Feb 24, 2006 at 04:23:19PM -0800, Josh Berkus wrote:
| Correct. Our uniqueness on constraints is:
| schema_name | table_name | constraint_name
|
| We're aware that it's a violation of SQL92, but there's no way for us to
| change it now without making it very hard for people to upgrade.
Clark,
> So it would seem that naming rules for constraints in PostgreSQL
> isn't exactly compliant with SQL92. I'm curious what sorts of
> constraints are enforced...
Correct. Our uniqueness on constraints is:
schema_name | table_name | constraint_name
We're aware that it's a violation of SQL
Hello all. I've got a question with regard to the INFORMATION_SCHEMA
of PostgreSQL, specificially related to constraints. In the SQL92
specification, the DEFINITION_SCHEMA.DOMAIN_CONSTRAINTS (the "imaginary"
base for INFORMATION_SCHEMA.DOMAIN_CONSTRAINTS), has a primary key:
CONSTRAINT_CATALOG,
42 matches
Mail list logo
