Re: Is a SERIAL column a "black box", or not?
От | elein |
---|---|
Тема | Re: Is a SERIAL column a "black box", or not? |
Дата | |
Msg-id | 20060503190848.GH5294@varlena.com обсуждение исходный текст |
Ответ на | Re: Is a SERIAL column a "black box", or not? ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
On Wed, May 03, 2006 at 10:12:28AM -0500, Jim C. Nasby wrote: > On Tue, May 02, 2006 at 07:45:13PM -0700, elein wrote: > > On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote: > > > On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote: > > > > On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote: > > > > > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > > > > > I think a big point that's being missed here is that SERIAL *is* trying > > > > > > to be simple. If you need something more sophisticated or complex you > > > > > > shouldn't be using SERIAL at all, you should be doing the stuff > > > > > > yourself, by hand. > > > > > > > > > > I agree with this point in the abstract, but one important proviso is > > > > > that it has to be *possible* to do it by hand. One good thing about > > > > > the "SERIAL is just a macro" approach is that it keeps us honest about > > > > > making sure that SERIAL isn't exploiting any weird internal behaviors > > > > > that are hard to duplicate for handmade sequence defaults. We've > > > > > already broken that to some extent by having the hidden dependency, > > > > > and that in turn means that fairly-reasonable expectations like > > > > > "pg_get_serial_sequence should find the column's associated sequence" > > > > > don't work on handmade sequences. I don't want to go much further in > > > > > that direction. If there's a usability problem we're trying to solve > > > > > for SERIALs, we should make sure the problem gets solved for handmade > > > > > sequences too. > > > > > > > > I agree with Tom's proviso and add one of my own, mentioned earlier. > > > > It should be easy to use a sequence w/alter sequence almost all of > > > > the time. The majority of the crowd should be able to use SERIAL in > > > > the majority of cases. One reason I am adamant about this is the > > > > v. useful dependencies that are (should be) set between the table > > > > and the sequence when it is declared as a SERIAL. > > > > > > I agree that we shouldn't be arbitrarily removing functionality from > > > SERIALs that would exist with a hand-grown sequence unless there's good > > > reason. > > > > > > I'm wondering if it would be best to essentially promote SERIALs to > > > being their own type of object? So instead of relying on a naming > > > convention or pg_get_serial_sequence to then make calls that touch the > > > underlying sequence (which probably shouldn't be directly accessible), > > > create functions/syntax that allows the required operations on a SERIAL > > > itself, such as table.column.nextval(), or nextval(table.column). > > > > > > Another way to look at this is how we handle VIEWS. Viwes are > > > implimented under-the-covers as a rule and some hidden table, yet we > > > don't support (or even allow?) people mucking with the stuff that's > > > under the hood. I think it would be best from a user standpoint if we > > > took the same approach with SERIAL, as long as we provide most of the > > > power that users would have from going the manual sequence route (I say > > > most because there's probably some oddball cases that wouldn't make > > > sense supporting, such as two SERIALS operating off the same sequence). > > > > This is not what I meant. I meant that most things should be able to be > > done by a combination of a SERIAL column definition plus ALTER SERIAL. > > But there are other reasons to have sequences as stand alone objects. > > I'm certainly not suggesting we remove sequences. What I'm saying is > that because a serial is intended to be a time saver, it should act like > one. That means no need to grant seperate permissions, and when you drop > the table or column, the serial should go away as well. > > > And don't get me started on how you cannot create a select rule. > > In that case the code to prevent proper use of create rules is probably > > as extensive as the code to implement views. > > Uhm, according to the docs you can create select rules. Or are you > suggesting that people should be able to muck around with the internals > of a view? I warned you not to get me started :) I retract my little side swipe to avoid going into that discussion here and now. This is not the appropriate thread. (But that does not mean I do not have opinions about the limitations of select rules, etc. :) ~elein > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "Jim Buttafuoco"Дата:
Сообщение: Re: drop database command blocking other connections
Следующее
От: Tom LaneДата:
Сообщение: Rethinking locking for database create/drop vs connection startup