Thread
-
Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-24T02:08:34Z
With the 6.4 beta just over a week away, here are the open items I see for 6.4. We actually have fewer than usual, so that is a good thing. Many of the latter ones are fairly rare bugs. --------------------------------------------------------------------------- change pg args for platforms that don't support argv changes (setproctitle()?, sendmail hack?) permissions on indexes: what do they do? should it be prevented? man pages/sgml synchronization (dump out man pages as postscript?) cidr/IP address type low level locking - status? improve reporting of syntax errors by showing location of error in query clean up username and indentifier length problems large object improvements use index with constants on functions allow chainging of pages to allow >8k tuples SERIAL type auto-creates sequence fix problem when DEFAULT string for CHAR() is not same as column remove PARSEDEBUG defines if not longer needed SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error CONSTRAINT does not pg_dump properly, paren problem double-quotes from pg_dump of field names document/trigger/rule so changes to pg_shadow create pg_pwd large objects issues improve group handling re-assign resno's for rewrite system order by mis-ordering result(Tom Lane/HPUX) have psql dump out rules text with new function Allow IN in DEFAULT section make identifiers 31 in scanner cnf-ify still can exhaust memory -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Peter Mount <peter@retep.org.uk> — 1998-08-24T07:34:24Z
On Sun, 23 Aug 1998, Bruce Momjian wrote: > With the 6.4 beta just over a week away, here are the open items I see > for 6.4. We actually have fewer than usual, so that is a good thing. > Many of the latter ones are fairly rare bugs. > > --------------------------------------------------------------------------- > > > large object improvements > large objects issues + Some JDBC Stuff I've been held up over the last 4 weeks with other things, but I'm putting most of this week aside to get these ready for the beta -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres Java PDF Generator: http://www.retep.org.uk/pdf -
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-24T15:27:59Z
> man pages/sgml synchronization (dump out man pages as postscript?) I'll need the sgml docs to firm up two weeks before release (Sept 15?) to give time to generate hardcopy. The admin guide will be the last converted, and it has the release notes and installation procedure which need to be updated. Can we think about how to do the release notes and installation for this release? I would suggest having a short readme on how to install and read the docs, and have the detailed installation procedure in sgml->html/hardcopy. > improve reporting syntax errors by showing location of error in query We haven't had this in previous releases. Not required for v6.4, right? > use index with constants on functions We haven't had this in previous releases. I know how to do it, I think, but am not seeing when I could get to it. How important is it?? > allow chainging of pages to allow >8k tuples One week before beta freeze. Won't be in v6.4, right? > SERIAL type auto-creates sequence I won't have time to do this for v6.4. It's not quite the same as the PRIMARY KEY parser solution, since the sequence must be created _before_ the main portion of the CREATE TABLE command is executed, rather than after. We should go through the high-level parser routines and allow all of them to return multiple parse trees; at the moment I've got a special-case workaround implemented for the PRIMARY KEY code which doesn't generalize very well. > fix problem when DEFAULT string for CHAR() is not same as column Who is pursuing this? Where does the problem come from? > remove PARSEDEBUG defines if not longer needed Yeah, yeah :) > double-quotes from pg_dump of field names I have some patches for this, but have not had time to test yet. > Allow IN in DEFAULT section Already done and in the cvs tree: postgres=> create table t (i int, check (i in (1, 2, 3))); CREATE I fixed NOT LIKE and NOT IN at the same time... - Tom -
Re: [HACKERS] Open 6.4 items
Brook Milligan <brook@trillium.nmsu.edu> — 1998-08-24T16:04:36Z
> SERIAL type auto-creates sequence I won't have time to do this for v6.4. It's not quite the same as the PRIMARY KEY parser solution, since the sequence must be created _before_ the main portion of the CREATE TABLE command is executed, rather than after. We should go through the high-level parser routines and allow all of them to return multiple parse trees; at the moment I've got a special-case workaround implemented for the PRIMARY KEY code which doesn't generalize very well. Actually, sequences can be defined _either_ before or after the table. See below. Cheers, Brook =========================================================================== -- create id sequence before table drop sequence id_sequence_before; create sequence id_sequence_before start 1; -- create table drop table id_table; create table id_table ( id_before int4 default nextval ('id_sequence_before'), id_after int4 default nextval ('id_sequence_after'), name text ); -- create id sequence after table drop sequence id_sequence_after; create sequence id_sequence_after start 1; -- populate table insert into id_table (name) values ('one'); insert into id_table (name) values ('two'); insert into id_table (name) values ('three'); select * from id_table; =========================================================================== id_before|id_after|name ---------+--------+----- 1| 1|one 2| 2|two 3| 3|three (3 rows) =========================================================================== -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-25T02:58:56Z
> > man pages/sgml synchronization (dump out man pages as postscript?) > > I'll need the sgml docs to firm up two weeks before release (Sept 15?) > to give time to generate hardcopy. The admin guide will be the last > converted, and it has the release notes and installation procedure which > need to be updated. Can we think about how to do the release notes and > installation for this release? I would suggest having a short readme on > how to install and read the docs, and have the detailed installation > procedure in sgml->html/hardcopy. Yep. Remember Marc's rule that you can't add features after beta starts, but you can be fixing things. That buys us a lot of time. > > > improve reporting syntax errors by showing location of error in query > > We haven't had this in previous releases. Not required for v6.4, right? Not required. Again, there are NEW items. If they don't get fixed, they are moved to the TODO list. > > > use index with constants on functions > > We haven't had this in previous releases. I know how to do it, I think, > but am not seeing when I could get to it. How important is it?? Probably too large for 6.4 at this point. > > > allow chainging of pages to allow >8k tuples > > One week before beta freeze. Won't be in v6.4, right? Right. > > > SERIAL type auto-creates sequence > > I won't have time to do this for v6.4. It's not quite the same as the > PRIMARY KEY parser solution, since the sequence must be created _before_ > the main portion of the CREATE TABLE command is executed, rather than > after. We should go through the high-level parser routines and allow all > of them to return multiple parse trees; at the moment I've got a > special-case workaround implemented for the PRIMARY KEY code which > doesn't generalize very well. This would be nice to have for 6.4. Someone mentioned you can create the sequence before the table, so maybe we can jam it in. If it is not 100% correct, we have a month to make it correct, right? > > > fix problem when DEFAULT string for CHAR() is not same as column > > Who is pursuing this? Where does the problem come from? I am attaching the posting describing the problem. If anyone wants to see the actual problem reports for any item, let me know. I can send you my entire mailbox of 70 items if you wish. > > > remove PARSEDEBUG defines if not longer needed > > Yeah, yeah :) Remember, I suggested a way you could keep them with more eligant defines. Any comments? > > > double-quotes from pg_dump of field names > > I have some patches for this, but have not had time to test yet. Cool. Let the beta testers test it! > > > Allow IN in DEFAULT section > > Already done and in the cvs tree: > postgres=> create table t (i int, check (i in (1, 2, 3))); > CREATE > > I fixed NOT LIKE and NOT IN at the same time... Great. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-25T03:59:12Z
> > man pages/sgml synchronization (dump out man pages as postscript?) > > I'll need the sgml docs to firm up two weeks before release (Sept 15?) > to give time to generate hardcopy. The admin guide will be the last > converted, and it has the release notes and installation procedure which > need to be updated. Can we think about how to do the release notes and > installation for this release? I would suggest having a short readme on > how to install and read the docs, and have the detailed installation > procedure in sgml->html/hardcopy. I wanted to comment on this. Are you going sgml crazy? :-) (We need more humor here.) Do we have to sgml everything? Perhaps we can add an sgml mode to psql like the html mode we have? I think some things that are referenced only occasionally or on screen are better left as flat text files. Why not just let them pull it up with more or vi? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-25T06:13:22Z
> Do we have to sgml everything? Perhaps we can add an sgml mode to > psql like the html mode we have? No, we don't have to sgml everything. But, it makes the difference between flat text files and true documentation. Not everyone wants to bother writing it, but it really makes the difference between hacker code and a usable system imho. > I think some things that are referenced only occasionally or on screen > are better left as flat text files. Why not just let them pull it up > with more or vi? That is possible. But why are fundamental things like installation instructions or release notes better left as flat files? Can't quite see why a user would think so. We can choose what docs we write and maintain for the system, and we can choose how we make them look. It maybe isn't too suprising how little interest people have in writing documentation, but I'm the wrong person to ask whether sgml is the right way to go. I'm currently listing 326 source and product files of documentation resources in the Postgres system (a few files are obsolete with conversion to sgml). This does not including html output files. There are 50 README files. There are over 88 man pages. These are all unstructured docs, with no clear organization. How should someone remember which README to look in? Or what man page to try?? It's a volume of information which needs organizing and structuring into a predictable presentation for a user. I'm using as my model for documentation those I've found useful over the years. None of them struck me as something better left as a flat text file. Anyway, that's my $0.02... - Tom -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-25T06:26:58Z
> > Do we have to sgml everything? Perhaps we can add an sgml mode to > > psql like the html mode we have? > > No, we don't have to sgml everything. But, it makes the difference > between flat text files and true documentation. Not everyone wants to > bother writing it, but it really makes the difference between hacker > code and a usable system imho. I am concerned about people installing on systems that don't have graphic monitors or can print postscript. What do we tell them? > > > I think some things that are referenced only occasionally or on screen > > are better left as flat text files. Why not just let them pull it up > > with more or vi? > > That is possible. But why are fundamental things like installation > instructions or release notes better left as flat files? Can't quite see > why a user would think so. We can choose what docs we write and maintain > for the system, and we can choose how we make them look. It maybe isn't > too suprising how little interest people have in writing documentation, > but I'm the wrong person to ask whether sgml is the right way to go. > > I'm currently listing 326 source and product files of documentation > resources in the Postgres system (a few files are obsolete with > conversion to sgml). This does not including html output files. There > are 50 README files. There are over 88 man pages. These are all > unstructured docs, with no clear organization. How should someone > remember which README to look in? Or what man page to try?? It's a > volume of information which needs organizing and structuring into a > predictable presentation for a user. I'm using as my model for > documentation those I've found useful over the years. None of them > struck me as something better left as a flat text file. > > Anyway, that's my $0.02... OK. As long as we can generate flat too for those that can't use fancy stuff. Certainly it is better than flat files if both are available for novices trying to get started. I agree we have TONS of stuff that needs serious organization. But I also like to have the stuff availble in quick format like man pages and ascii files that I can grep and pull up quickly. psql has the \h help command because it gives people information in a handy way. Man pages are the same. 'more INSTALL' may be the same? Right now, we have great docs that someone can sit down and read as a book, chapter by chapter. For people who are in the middle of something, psql \h or man or 'more INSTALL' may be easier, and no one is really going to sit down and study those, I think. Maybe I am wrong. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-25T06:28:35Z
> > > SERIAL type auto-creates sequence > This would be nice to have for 6.4. Someone mentioned you can create > the sequence before the table, so maybe we can jam it in. If it is not > 100% correct, we have a month to make it correct, right? postgres=> create table s (x text, i serial); NOTICE: CREATE TABLE will create implicit sequence s_i_seq for SERIAL column s.i CREATE postgres=> insert into s values ('one'); INSERT 894455 1 postgres=> insert into s values ('two'); INSERT 894456 1 postgres=> insert into s values ('three'); INSERT 894457 1 postgres=> select * from s; x |i -----+- one |1 two |2 three|3 (3 rows) > > > remove PARSEDEBUG defines if not longer needed > Remember, I suggested a way you could keep them with more eligant > defines. Any comments? Well, I think that at least most of them should come out of the code altogether. The more elegant solution probably leads to code clutter also, just a bit more readable since it indents with the rest of the code. > > > double-quotes from pg_dump of field names > > I have some patches for this, but have not had time to test yet. > Cool. Let the beta testers test it! Hmm. So that would make them alpha testers, right? :) Might be OK for this one, if someone is willing to try it. I'd hate to make a change and then forget about it though. Tatsuo? - Tom -
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-25T15:32:43Z
> > > SERIAL type auto-creates sequence > > I won't have time to do this for v6.4. > This would be nice to have, so maybe we can jam it in. If it is not > 100% correct, we have a month to make it correct, right? OK, I've committed the SERIAL type support to the CVS tree: postgres=> create table test (x text, s serial); NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL column test.s NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for table test CREATE postgres=> insert into test values ('one'); INSERT 894781 1 postgres=> insert into test values ('two'); INSERT 894782 1 postgres=> insert into test values ('three'); INSERT 894783 1 postgres=> select * from test; x |s -----+- one |1 two |2 three|3 (3 rows) postgres=> \d Database = postgres +------------------+----------------------------------+----------+ | Owner | Relation | Type | +------------------+----------------------------------+----------+ | postgres | test | table | | postgres | test_s_key | index | | postgres | test_s_seq | sequence | +------------------+----------------------------------+----------+ postgres=> select * from test; x |s -----+- one |1 two |2 three|3 (3 rows) postgres=> \d pqReadData() -- backend closed the channel unexpectedly. Whoops! Don't know why this is causing trouble, but it seems to be reproducible. Will look at it some more... - Tom -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-25T17:31:31Z
> > > > SERIAL type auto-creates sequence > > This would be nice to have for 6.4. Someone mentioned you can create > > the sequence before the table, so maybe we can jam it in. If it is not > > 100% correct, we have a month to make it correct, right? > > postgres=> create table s (x text, i serial); > NOTICE: CREATE TABLE will create implicit sequence s_i_seq for SERIAL > column s.i > CREATE > postgres=> insert into s values ('one'); > INSERT 894455 1 > postgres=> insert into s values ('two'); > INSERT 894456 1 > postgres=> insert into s values ('three'); > INSERT 894457 1 > postgres=> select * from s; > x |i > -----+- > one |1 > two |2 > three|3 > (3 rows) Great. > > > > > remove PARSEDEBUG defines if not longer needed > > Remember, I suggested a way you could keep them with more eligant > > defines. Any comments? > > Well, I think that at least most of them should come out of the code > altogether. The more elegant solution probably leads to code clutter > also, just a bit more readable since it indents with the rest of the > code. OK. I just redid parse_target.c, so I hope you can merge in your stuff. > > > > > double-quotes from pg_dump of field names > > > I have some patches for this, but have not had time to test yet. > > Cool. Let the beta testers test it! > > Hmm. So that would make them alpha testers, right? :) Might be OK for > this one, if someone is willing to try it. I'd hate to make a change and > then forget about it though. Tatsuo? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h) -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-25T17:55:07Z
> postgres=> select * from test; > x |s > -----+- > one |1 > two |2 > three|3 > (3 rows) > > postgres=> \d > pqReadData() -- backend closed the channel unexpectedly. > > Whoops! Don't know why this is causing trouble, but it seems to be > reproducible. Will look at it some more... While you are in there, how does \d show sequences. I have \d table showing the indexes. Can it show sequences too? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Nick Bastin <nbastin@rbbsystems.com> — 1998-08-25T19:50:43Z
Bruce Momjian wrote: > > > > man pages/sgml synchronization (dump out man pages as postscript?) > > > > I'll need the sgml docs to firm up two weeks before release (Sept 15?) > > to give time to generate hardcopy. The admin guide will be the last > > converted, and it has the release notes and installation procedure which > > need to be updated. Can we think about how to do the release notes and > > installation for this release? I would suggest having a short readme on > > how to install and read the docs, and have the detailed installation > > procedure in sgml->html/hardcopy. > > Yep. Remember Marc's rule that you can't add features after beta > starts, but you can be fixing things. That buys us a lot of time. Not to point out the obvious, but that's what beta traditionally *means*... 'feature complete'. Nick
-
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-08-25T21:41:17Z
On Tue, 25 Aug 1998, Nick Bastin wrote: > Bruce Momjian wrote: > > > > > > man pages/sgml synchronization (dump out man pages as postscript?) > > > > > > I'll need the sgml docs to firm up two weeks before release (Sept 15?) > > > to give time to generate hardcopy. The admin guide will be the last > > > converted, and it has the release notes and installation procedure which > > > need to be updated. Can we think about how to do the release notes and > > > installation for this release? I would suggest having a short readme on > > > how to install and read the docs, and have the detailed installation > > > procedure in sgml->html/hardcopy. > > > > Yep. Remember Marc's rule that you can't add features after beta > > starts, but you can be fixing things. That buys us a lot of time. > > Not to point out the obvious, but that's what beta traditionally *means*... > 'feature complete'. Ya, we know that...:) Bruce is trying make fun of me *sniffle* *grin* Once we go beta, I tend to be quite...anal(?) about adding anything unless 100% absolutely necessary, so the idea is to sneak as many new features as possible in before it goes beta, even if they are buggy, cause then "the feature is there, just has a few bugs to fix" *grin* Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items
Henry B. Hotz <hotz@jpl.nasa.gov> — 1998-08-26T00:13:34Z
At 11:26 PM -0700 8/24/98, Bruce Momjian wrote: >> That is possible. But why are fundamental things like installation >> instructions or release notes better left as flat files? Can't quite see > >OK. As long as we can generate flat too for those that can't use fancy >stuff. Certainly it is better than flat files if both are available for >novices trying to get started. > My $.02. Having just built a new server I like the fact that most packages (gcc, apache, perl) have a top-level INSTALL and README file. They are flat files so you can look at them before you have installed anything. I like the convention. More specifically you shouldn't have to install anything to read the INSTALL file. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
-
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-26T03:03:48Z
> > > Yep. Remember Marc's rule that you can't add features after beta > > > starts, but you can be fixing things. That buys us a lot of time. > > > > Not to point out the obvious, but that's what beta traditionally *means*... > > 'feature complete'. > > Ya, we know that...:) Bruce is trying make fun of me *sniffle* > *grin* Once we go beta, I tend to be quite...anal(?) about adding > anything unless 100% absolutely necessary, so the idea is to sneak as many > new features as possible in before it goes beta, even if they are buggy, > cause then "the feature is there, just has a few bugs to fix" *grin* Good analysis. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-08-26T03:44:00Z
On Tue, 25 Aug 1998, Bruce Momjian wrote: > > > > Yep. Remember Marc's rule that you can't add features after beta > > > > starts, but you can be fixing things. That buys us a lot of time. > > > > > > Not to point out the obvious, but that's what beta traditionally *means*... > > > 'feature complete'. > > > > Ya, we know that...:) Bruce is trying make fun of me *sniffle* > > *grin* Once we go beta, I tend to be quite...anal(?) about adding > > anything unless 100% absolutely necessary, so the idea is to sneak as many > > new features as possible in before it goes beta, even if they are buggy, > > cause then "the feature is there, just has a few bugs to fix" *grin* > > Good analysis. We've worked together for much much to long for us not to have a pretty good "feel" for each other :) Produce some good work, no? :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items]
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-26T04:47:32Z
> > > Ya, we know that...:) Bruce is trying make fun of me *sniffle* > > > *grin* Once we go beta, I tend to be quite...anal(?) about adding > > > anything unless 100% absolutely necessary, so the idea is to sneak as many > > > new features as possible in before it goes beta, even if they are buggy, > > > cause then "the feature is there, just has a few bugs to fix" *grin* > > > > Good analysis. > > We've worked together for much much to long for us not to have a > pretty good "feel" for each other :) Produce some good work, no? :) > You bet. Very good work, and getting better every day. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Open 6.4 items
Peter Mount <peter@retep.org.uk> — 1998-08-30T10:55:03Z
On Tue, 25 Aug 1998, Thomas G. Lockhart wrote: > > > > SERIAL type auto-creates sequence > > > I won't have time to do this for v6.4. > > This would be nice to have, so maybe we can jam it in. If it is not > > 100% correct, we have a month to make it correct, right? > > OK, I've committed the SERIAL type support to the CVS tree: > > postgres=> create table test (x text, s serial); > NOTICE: CREATE TABLE will create implicit sequence test_s_seq for > SERIAL column test.s > NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for > table test > CREATE I've just tried this (using a CVS tree from Friday), and got this: peter=> create table test (x text, s serial); NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL column test.s NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for table test ERROR: pg_aclcheck: class "test_s_seq" not found \d shows that nothing is created. Any ideas? -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres Java PDF Generator: http://www.retep.org.uk/pdf -
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-30T18:40:52Z
Works fine _if_ the user has database creation privileges: tgl=> create table test (x text, s serial); NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL column test.s NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for table test CREATE This statement internally expands to roughly the following: create table test (x text, s int4 default nextval('test_s_seq')); create unique index test_s_key on test (s); create sequence test_s_seq; If the user has no database creation privileges, then apparently there is some checking which insists that the sequence referenced in the implicit default clause actually exists: tgl=> create table test (x text, i int default nextval('test_s_seq')); ERROR: pg_aclcheck: class "test_s_seq" not found So, it looks like the sequence should internally be created before the table, though in some cases it doesn't matter. I was concerned that this might be the case, and the parser is not at the moment configured to allow this. Should be able to fix it up, or have just limited SERIAL support for the v6.4 release :( - Tom -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-30T21:11:21Z
> Works fine _if_ the user has database creation privileges: Can I ask why sequence creation is related to database CREATION. Seems very strange to me. > > tgl=> create table test (x text, s serial); > NOTICE: CREATE TABLE will create implicit sequence test_s_seq for SERIAL > column test.s > NOTICE: CREATE TABLE/UNIQUE will create implicit index test_s_key for > table test > CREATE > > This statement internally expands to roughly the following: > create table test (x text, s int4 default nextval('test_s_seq')); > create unique index test_s_key on test (s); > create sequence test_s_seq; > > If the user has no database creation privileges, then apparently there > is some checking which insists that the sequence referenced in the > implicit default clause actually exists: > > tgl=> create table test (x text, i int default nextval('test_s_seq')); > ERROR: pg_aclcheck: class "test_s_seq" not found > > So, it looks like the sequence should internally be created before the > table, though in some cases it doesn't matter. I was concerned that this > might be the case, and the parser is not at the moment configured to > allow this. Should be able to fix it up, or have just limited SERIAL > support for the v6.4 release :( > > - Tom > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h) -
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-08-30T23:07:07Z
> > Works fine _if_ the user has database creation privileges: > Can I ask why sequence creation is related to database CREATION. > Seems very strange to me. I'd guess that it is related to being allowed to put entries into whatever supports sequences (a view or table?). If you created the database you get some other privileges too?? > > tgl=> create table test (x text, > > tgl-> i int default nextval('test_s_seq')); > > ERROR: pg_aclcheck: class "test_s_seq" not found > > it looks like the sequence should internally be created before the > > table, though in some cases it doesn't matter. I was concerned that > > this might be the case, and the parser is not at the moment > > configured to allow this. - Tom