At 02:59 AM 8/11/2003, Tom Lane wrote:
These are mutually exclusive --- I see no reason to do both.
Not sure that's true; we've taken te design decision to make allow
user-defined constraint names to be non-unique. Given that, I think we
should allow people who fall into the trap to be able to us
Barry Lind wrote:
>
>
> Tom Lane wrote:
> >
> >>Using tableoid instead of tablename avoids renaming problems, but makes
> >>the names horribly opaque IMNSHO.
> >
> >
> > Agreed. I think using the OIDs would be a horrible choice.
> >
>
> As a point of reference Oracle uses a naming conventi
Tom Lane wrote:
Using tableoid instead of tablename avoids renaming problems, but makes
the names horribly opaque IMNSHO.
Agreed. I think using the OIDs would be a horrible choice.
As a point of reference Oracle uses a naming convention of 'C' where
is a sequence generated unique
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
. add tableoid or tablename to information_schema.{check_constraints,
referential_constraints} (I think those are the only places where it
would be needed, from my quick skimming).
. add tableoid or tablename to autogenerated table
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think there are several of them from this thread:
> . make autogenerated column constraint names unique per table (by adding
> "_$n" ?)
Check.
> . add tableoid or tablename to information_schema.{check_constraints,
> referential_constraints} (I th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> regression=# create table foo (f1 int check (f1 > 0) check (f1 < 10));
> >> ERROR: check constraint "foo_f1" already exists
>
> > Is this a TODO to fix?
>
> Probably should be. I'd be inclined to try to fix it
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> regression=# create table foo (f1 int check (f1 > 0) check (f1 < 10));
>> ERROR: check constraint "foo_f1" already exists
> Is this a TODO to fix?
Probably should be. I'd be inclined to try to fix it by generating
"foo_f1_1", "foo_f
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote:
I don't have a problem with switching from "$1" to "tablename_$1", or
some such, for auto-generated constraint names. But if it's not
guaranteed
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote:
> >> I don't have a problem with switching from "$1" to "tablename_$1", or
> >> some such, for auto-generated constraint names. But if it's not
> >> guaranteed unique, does it
At 11:38 AM 7/11/2003, Tom Lane wrote:
Your argument that we should add the table name to the view does have
some merit though.
Sounds good to me. It would need to be added to each view that has
constraint_name, then we should be able to cross the info schema views and
get meaningful data.
-
Philip Warner <[EMAIL PROTECTED]> writes:
> Peter may have been alluding to this, and I misunderstood, but one idea
> might be to present a mangled name in the information schema; since the
> spec expects them to be unique, perhaps the schema should present them as
> unique.
Doesn't seem like t
At 10:54 AM 7/11/2003, Philip Warner wrote:
add table OID (or something else) to the information schema
Peter may have been alluding to this, and I misunderstood, but one idea
might be to present a mangled name in the information schema; since the
spec expects them to be unique, perhaps the schem
Philip Warner wrote:
At 03:37 AM 7/11/2003, Peter Eisentraut wrote:
It would
already help a lot if we just added the table name, or something that
was
until a short time before the action believed to be the table name, or
even only the table OID, before (or after) the $1.
Can we allow/bypass
At 03:37 AM 7/11/2003, Peter Eisentraut wrote:
It would
already help a lot if we just added the table name, or something that was
until a short time before the action believed to be the table name, or
even only the table OID, before (or after) the $1.
Can we allow/bypass the pg_* restriction, and c
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
I don't think we really need a method to guarantee unique names. It would
already help a lot if we just added the table name, or something that was
until a short time before the action believed to be the table name, or
even only the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote:
>> I don't have a problem with switching from "$1" to "tablename_$1", or
>> some such, for auto-generated constraint names. But if it's not
>> guaranteed unique, does it really satisfy Philip's c
On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I don't think we really need a method to guarantee unique names. It would
> > already help a lot if we just added the table name, or something that was
> > until a short time before the act
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't think we really need a method to guarantee unique names. It would
> already help a lot if we just added the table name, or something that was
> until a short time before the action believed to be the table name, or
> even only the table OID, b
Tom Lane writes:
> > Would a good halfway house be to ensure that generated names were unique
> > within a schema (e.g. instead of generating "$1" generate
> > "tablename$1")?
>
> No, because that buys into all of the serialization and deadlocking
> problems that doing it the spec's way entail
I
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> The reason the spec defines these views this way is that it expects
>> constraint names to be unique across a whole schema. We don't enforce
>> that, and I don't think we want to start doing so (that was already
>> proposed and shot down at least once)
Tom Lane wrote:
The reason the spec defines these views this way is that it expects
constraint names to be unique across a whole schema. We don't enforce
that, and I don't think we want to start doing so (that was already
proposed and shot down at least once). You are of course free to use
const
Philip Warner <[EMAIL PROTECTED]> writes:
> Notice that the two records are identical because the two constraint names
> are the same. ISTM that we should have a way of usefully examining specific
> constraints without having to name them. Can we add the constraint OID or
No. The schemas of th
Just looking at the information schema in 7.4 and noticed something
odd/annoying/problematic:
create table pk(f1 int primary key);
create table fk1(f1 int references pk(f1));
create table fk2(f1 int references pk(f1));
select * from information_schema.referential_constraints;
-[ RECORD 1 ]--
23 matches
Mail list logo
