Обсуждение: Asserting existing key to be primary
I have a table that has a candidate primary key (e.g. - unique, not null) that I wish to actually assert _is_ a primary key. Is there a way to do that without too much (mwahahhaha! fiddling with pg_class!!!) trickery? -- (format nil "~S@~S" "cbbrowne" "acm.org") http://cbbrowne.com/info/emacs.html "What we need is either less corruption, or more chance to participate in it." -- Unknown
> Is there a way to do that without too much (mwahahhaha! fiddling with > pg_class!!!) trickery? esp=# alter table test add primary key(id); NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "test_pkey" for table "test" ALTER TABLE
Chris Browne <cbbrowne@acm.org> writes:
> I have a table that has a candidate primary key (e.g. - unique, not
> null) that I wish to actually assert _is_ a primary key.
> Is there a way to do that without too much (mwahahhaha! fiddling with
> pg_class!!!) trickery?
Why don't you just ALTER TABLE ADD PRIMARY KEY and then drop the
existing unique constraint?
You could probably fool with pg_constraint and pg_index to manually
transform the unique constraint into a pkey constraint, but the odds
of messing it up seem to outweigh the possible time savings.
regards, tom lane
Please could we have a development schedule page on the web site...? The information it should contain would be like this (and others) Current Development Release: (Coordinator: Bruce Momjian)8.0: Beta1, released 2 August 2004 Beta2, deadline 2 September2004 Doc Freeze, deadline 12 September 2004 Release, planned 2 October 2004 Stable Releases: (Coordinator: Bruce Momjian)7.4 Stable: 7.4.3, released XYZ Security advisory(s) exist for 7.4.17.3 Stable: 7.3.6, released XYZ Security advisory(s) exist for 7.3.5 and below Previous Releases: (No Coordinator)7.2 Stable: 7.2.4, released XYZ Advice: Upgrade now to 7.4 stable7.1 Stable:7.1.3, released XYZ Advice: Upgrade now to 7.4 stable Next Release: (Coordinator: Bruce Momjian)8.1 Beta Freeze, deadline 1 June 2005 Once we have the page, we can start to discuss the details on it. I remain mostly in the dark about how many beta phases there will be what their deadlines are etc. If we know this, its easy to write down, surely? Best Regards, Simon Riggs
"Simon@2ndquadrant.com" <simon@2ndquadrant.com> writes:
> Please could we have a development schedule page on the web site...?
You haven't been around here long, have you? There is no schedule.
The page would spend most of its time looking like
Current Development Release: (Coordinator: Bruce Momjian)8.0: Beta1, released 2 August 2004 Beta2, when it's
ready Doc Freeze, when it's ready Release, when it's ready
which isn't all that useful.
As for the historical aspect, we already have the past release notes
collected handily in the documentation, so I'm not sure what else we
need to do there.
regards, tom lane
> Tom Lane > > "Simon@2ndquadrant.com" <simon@2ndquadrant.com> writes: > > Please could we have a development schedule page on the web site...? > > You haven't been around here long, have you? Gee, Tom, you noticed? What gave it away? :) (I wasn't in a legal position to contribute before late 2003 - binding IP clauses and all that). > There is no schedule. Hmm..... I did think that at first. But I don't go with the mystical stuff. (There IS a spoon, Matrix-fans, IMHO.) Now, I think the answer is close to "Tom and/or Bruce know, but maybe they don't agree yet...." My observed group behaviour for what days is eventually agreed is something like: (Tom+Bruce+Marc)/2 in julian days I see this: there is no PUBLISHED schedule, there probably is no AGREED schedule, but everybody's working to some reasonable working assumptions which mean that there is in fact an IMPLICIT schedule. (Whether or not that changes over time) I argued as strongly as anyone to NOT follow the agreed plan (just recently). But I'm in favour of a published plan, so we all know. Just like my recipe book says "90 mins for a cake", but we keep cooking it till it looks good and don't try to flame Mrs.Beeton because it took 95 mins. My interest is in allowing others to contribute. I have many other ideas in this vein. We can put things to the nearest month, if thats all we know/decide we can hold ourselves to.... Best Regards, Simon Riggs
On Friday 13 August 2004 19:37, Tom Lane wrote:
> "Simon@2ndquadrant.com" <simon@2ndquadrant.com> writes:
> > Please could we have a development schedule page on the web site...?
>
> You haven't been around here long, have you? There is no schedule.
>
> The page would spend most of its time looking like
>
> Current Development Release: (Coordinator: Bruce Momjian)
> 8.0: Beta1, released 2 August 2004
> Beta2, when it's ready
> Doc Freeze, when it's ready
> Release, when it's ready
>
> which isn't all that useful.
Not sure how much more useful this is, but generally the first RC goes out
once all the open items are dealt with. Also doc freeze is generally
expected at RC1 time (though errors in the docs are still acceptable fixes
for subsequent RC's) We do RC's as needed until core feels they will produce
no more bug reports in a timely fasion, and then release happens.
--
Robert Treat
Build A Better Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
> Not sure how much more useful this is, but generally the first RC goes out
> once all the open items are dealt with. Also doc freeze is generally
> expected at RC1 time (though errors in the docs are still acceptable fixes
> for subsequent RC's)
Actually I'm not sure that we generally have a docs freeze at all.
The reference pages may freeze a bit before release, because there
is some manual effort needed to produce the man-page formatted files
from them. But that's an artifact of our current document generation
toolset rather than something that anyone finds desirable. The SGML
docs can surely be worked on right up till release.
Of course it is better to get major docs changes in sooner rather than
later, if only so other people have a chance to look 'em over.
regards, tom lane
"Simon@2ndquadrant.com" <simon@2ndquadrant.com> writes:
> I see this: there is no PUBLISHED schedule, there probably is no AGREED
> schedule, but everybody's working to some reasonable working assumptions
> which mean that there is in fact an IMPLICIT schedule. (Whether or not that
> changes over time)
Well, if you want a page that says "Release: maybe October-ish???" we
could do that, but I'm really dubious about the value. ISTM that if you
follow -hackers you will have a feeling for how beta is going, and if
you don't then you won't. No summary webpage is going to give you
insight that the people doing the work don't have themselves.
> We can put things to the nearest month, if thats all we know/decide we can
> hold ourselves to....
Nearest month is far more specific than I care to be at the moment.
I would give good odds that 8.0 will be released before the end of the
year, but I'd not write down a month yet. In another month, if beta
seems to be going well, I would be ready to get more specific.
regards, tom lane