Christopher Kings-Lynne wrote:
> Speaking of - I simply cannot find a standard SQL specification anywhere on
> the net, without buying one from ANSI. I'm forced to rely on
> vendor-specific docs - which are not standard in any way. Is anyone able to
> mail me such a thing?
You may want to take
>
> On Tue, 21 Nov 2000, Christopher Kings-Lynne wrote:
>
> > > > Problem is that there are 5 difference types of constraints,
> > > implemented in
> > > > 5 different ways. Do you want a unifed, central catalog of
> > > constraints, or
> > > > just for some of them, or what?
> > >
> > > Dunno.
On Tue, 21 Nov 2000, Christopher Kings-Lynne wrote:
> > > Problem is that there are 5 difference types of constraints,
> > implemented in
> > > 5 different ways. Do you want a unifed, central catalog of
> > constraints, or
> > > just for some of them, or what?
> >
> > Dunno. Maybe a unified re
At 12:18 AM 11/21/00 -0500, Tom Lane wrote:
>Don Baccus <[EMAIL PROTECTED]> writes:
>> If this problem is attacked, should one stop at constraints or make certain
>> that other elements like views are dumped properly, too? (or were views
>> fixed for 7.1, I admit to a certain amount of "ignoring
At 15:10 21/11/00 +0800, Christopher Kings-Lynne wrote:
>> CREATE TABLE example
>> ( example_id serial
>>
>> -- Must be a ZIP or Postal Code
>> , regionvarchar(6)
>>
>> -- Descriptive text
>> , description varchar(60)
>> );
>
>Actually - this is something I _could_ do.
>
>As the pg_
> CREATE TABLE example
> ( example_id serial
>
> -- Must be a ZIP or Postal Code
> , regionvarchar(6)
>
> -- Descriptive text
> , description varchar(60)
> );
Actually - this is something I _could_ do.
As the pg_dump is running, it shouldn't be too hard to select the comment
assoc
At 00:22 21/11/00 -0500, Rod Taylor wrote:
>Christopher Kings-Lynne wrote:
>
>/***
> * TABLE: example
> *
> * Used to accomplish stuff
> */
>CREATE TABLE example
> ( example_id serial
>
> /* Must be a ZIP or Postal Code */
> , regionvarchar(6) UNIQUE
>
Christopher Kings-Lynne wrote:
>
> > I like this conversation as not a day goes by where I don't wish I could
> > edit the dump of a database rather than keeping structure entirely
> > seperate -- and actually do so in a useful manner. That said, whats the
> > possibility of maintaining comments
> Speaking of - I simply cannot find a standard SQL specification anywhere on
> the net, without buying one from ANSI. I'm forced to rely on
> vendor-specific docs - which are not standard in any way. Is anyone able to
> mail me such a thing?
Check the mailing list archives for the reference to
At 12:03 AM 11/21/00 -0500, Tom Lane wrote:
>Peter has remarked that the SQL spec offers a set of system views
>intended to provide exactly this info. That should be looked at;
>if there's a workable standard for this stuff, we oughta follow it.
This and a BUNCH else.
- Don Baccus, Portland
Don Baccus <[EMAIL PROTECTED]> writes:
> If this problem is attacked, should one stop at constraints or make certain
> that other elements like views are dumped properly, too? (or were views
> fixed for 7.1, I admit to a certain amount of "ignoring pgsql-hackers over
> the last few months")
Over
At 10:49 PM 11/20/00 -0500, Tom Lane wrote:
>"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Just to catch up here - does this mean that pg_dump has issues with
>> correctly recreating the contraints?
>
>Well, if you examine the pg_dump output, it doesn't really try ---
>you'll see no sig
* Christopher Kings-Lynne <[EMAIL PROTECTED]> [001120 23:10]:
> Speaking of - I simply cannot find a standard SQL specification anywhere on
> the net, without buying one from ANSI. I'm forced to rely on
> vendor-specific docs - which are not standard in any way. Is anyone able to
> mail me such
> A join as such doesn't bother me. For example, it'd be proper for this
> hypothetical constraint catalog to have a column of table OIDs, which
> you'd have to join against pg_class to get the table name from. The
> real issue is to make sure that we store enough info so that the
> original tab
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
> >>
> >> Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
> >> TRIGGER) would also be great.
>
> > In fact, IMHO, this would be a great place to start: we'
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> For example, say, if a catalog existed that clients could query to discover
> all constraint information, then it would be possible to change how foreign
> keys are implemented, and not affect how this info is presented.
> However, if users
> > Problem is that there are 5 difference types of constraints,
> implemented in
> > 5 different ways. Do you want a unifed, central catalog of
> constraints, or
> > just for some of them, or what?
>
> Dunno. Maybe a unified representation would make more sense, or maybe
> it's OK to treat them
> I like this conversation as not a day goes by where I don't wish I could
> edit the dump of a database rather than keeping structure entirely
> seperate -- and actually do so in a useful manner. That said, whats the
> possibility of maintaining comments if the SQL dumps actually became
> humanl
Tom Lane wrote:
> > It would be nice, however, if pg_dump produced the exact same sql as used to
> > create a table. For instance, if you specify a column constraint, it comes
> > back as a column constraint, rather than a trigger, or a table constraint.
> > This would especially aid portability
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Just to catch up here - does this mean that pg_dump has issues with
> correctly recreating the contraints?
Well, if you examine the pg_dump output, it doesn't really try ---
you'll see no sign of any foreign-key constraint declarations in
a
> > In fact, IMHO, this would be a great place to start: we'd all love the
> > fuctionality, it'd have you examining almost all the same code, and it'd
> > be a feature we could all test, in diverse situations. DROP CONSTRAINT
> > is unlikely to be as widely tested. If you can build the introspect
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > * I assume that the command is supposed to allow the dropping of unique,
> > primary, foreign key and check constraints? Should 'not null'
> constraints
> > also be included here?
OK, I have just checked the SQL standard thingy for DROP
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
>>
>> Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
>> TRIGGER) would also be great.
> In fact, IMHO, this would be a great place to start: we'd all love the
On Mon, Nov 20, 2000 at 06:52:20PM +0200, Hannu Krosing wrote:
>
> Dumping constraints in human-readable form (instead of CREATE CONSTRAIN
> TRIGGER) would also be great.
In fact, IMHO, this would be a great place to start: we'd all love the
fuctionality, it'd have you examining almost all the s
Tom Lane wrote:
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > * I assume that the command is supposed to allow the dropping of unique,
> > primary, foreign key and check constraints? Should 'not null' constraints
> > also be included here?
>
> Sure.
>
> > * Unique constraints a
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> * I assume that the command is supposed to allow the dropping of unique,
> primary, foreign key and check constraints? Should 'not null' constraints
> also be included here?
Sure.
> * Unique constraints are implemented as indicies, so drop
Hi,
I was looking at the ALTER TABLE DROP CONSTRAINT bit of PostgreSQL, and I
started thinking about trying to implement it (as a bit of mental exercise).
(And because it's highly annoying not being able to remove the damn things!
Please comment on all of this, and tell me if it's going to be ov
27 matches
Mail list logo
