Thread: Open 6.4 items
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)
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
> 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
> 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)
===========================================================================
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> 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.
I had a few other things on my list:
* make PGconn,PGresult truly opaque to applications (per recent discussion)
* libpgtcl is missing any way to access PQerrorMessage!?
* remove writable fields in static PQconninfoOptions for thread safety
* bring libpq.sgml documentation fully up to speed
(I'm willing to do the above four, but am not promising that the doco
will get done before Sept 1. I think Thomas indicated that Sept 15
is OK for docs?)
* put UNLISTEN in standard backend, fix libpgtcl listen support to use it
I would really like to see this in 6.4, because I need UNLISTEN in my
applications. Thomas had volunteered to add the needed parser support
for UNLISTEN (the execution function already exists, it just needs a
statement that can call it). As far as I've heard he hasn't gotten to
it yet. I can fix libpgtcl but do not want to touch it unless the
underlying backend support is there.
* psql: control-c ought to stop lengthy output
* psql's \z output truncates table names at 16 chars
* psql and libpgtcl insert unexpected backslashes in output data
I was going to work on these but it's looking like they will not make
the Sept 1 cut. Anyone else want to do them?
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
I'd like to see this in there too, and will work on it if no one else
does, but I rather doubt I can get to it by Sept 1. Maybe this will
have to wait for 6.5, or 6.4.1, or something.
regards, tom lane
> > 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)
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > 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. > > I had a few other things on my list: > > * make PGconn,PGresult truly opaque to applications (per recent discussion) > * libpgtcl is missing any way to access PQerrorMessage!? > * remove writable fields in static PQconninfoOptions for thread safety > * bring libpq.sgml documentation fully up to speed > > (I'm willing to do the above four, but am not promising that the doco > will get done before Sept 1. I think Thomas indicated that Sept 15 > is OK for docs?) Sounds good to me. > > * put UNLISTEN in standard backend, fix libpgtcl listen support to use it > > I would really like to see this in 6.4, because I need UNLISTEN in my > applications. Thomas had volunteered to add the needed parser support > for UNLISTEN (the execution function already exists, it just needs a > statement that can call it). As far as I've heard he hasn't gotten to > it yet. I can fix libpgtcl but do not want to touch it unless the > underlying backend support is there. > > * psql: control-c ought to stop lengthy output > * psql's \z output truncates table names at 16 chars > * psql and libpgtcl insert unexpected backslashes in output data > > I was going to work on these but it's looking like they will not make > the Sept 1 cut. Anyone else want to do them? Not really sure anyone else knows those areas. I am surprised by the psql \z. Of course, if you add the "features" now, you can fix the bugs during beta. > > > > change pg args for platforms that don't support argv changes > > (setproctitle()?, sendmail hack?) > > I'd like to see this in there too, and will work on it if no one else > does, but I rather doubt I can get to it by Sept 1. Maybe this will > have to wait for 6.5, or 6.4.1, or something. Again, can be done later. Will be a problem without the fix. -- 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)
> > 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)
> 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
> > > 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
> > 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)
>> > > 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? You could send me the patch. I also have another problem with 6.3.2 pg_dump regarding 8bit or Upper case letters handling and some fixes for that. I would like to merge the fixes into 6.4. -- Tatsuo Ishii t-ishii@sra.co.jp
> You could send me the patch. I also have another problem with 6.3.2
> pg_dump regarding 8bit or Upper case letters handling and some fixes
> for that. I would like to merge the fixes into 6.4.
OK, here is the patch. However, I've also already committed the patch to
the CVS source tree; hope that doesn't make it more difficult for you.
Thanks.
- Tom
*** ../src/bin/pg_dump/pg_dump.c.orig Thu Aug 6 05:12:51 1998
--- ../src/bin/pg_dump/pg_dump.c Tue Aug 18 05:57:44 1998
***************
*** 221,235 ****
if (oids)
{
! fprintf(fout, "COPY \"%s\" WITH OIDS FROM stdin;\n",
fmtId(classname));
! sprintf(query, "COPY \"%s\" WITH OIDS TO stdout;\n",
fmtId(classname));
}
else
{
! fprintf(fout, "COPY \"%s\" FROM stdin;\n", fmtId(classname));
! sprintf(query, "COPY \"%s\" TO stdout;\n", fmtId(classname));
}
res = PQexec(g_conn, query);
if (!res ||
--- 221,235 ----
if (oids)
{
! fprintf(fout, "COPY %s WITH OIDS FROM stdin;\n",
fmtId(classname));
! sprintf(query, "COPY %s WITH OIDS TO stdout;\n",
fmtId(classname));
}
else
{
! fprintf(fout, "COPY %s FROM stdin;\n", fmtId(classname));
! sprintf(query, "COPY %s TO stdout;\n", fmtId(classname));
}
res = PQexec(g_conn, query);
if (!res ||
***************
*** 316,322 ****
int tuple;
int field;
! sprintf(query, "SELECT * FROM \"%s\"", classname);
res = PQexec(g_conn, query);
if (!res ||
PQresultStatus(res) != PGRES_TUPLES_OK)
--- 316,322 ----
int tuple;
int field;
! sprintf(query, "SELECT * FROM %s", fmtId(classname));
res = PQexec(g_conn, query);
if (!res ||
PQresultStatus(res) != PGRES_TUPLES_OK)
***************
*** 327,333 ****
tuple = 0;
while (tuple < PQntuples(res))
{
! fprintf(fout, "INSERT INTO \"%s\" ", fmtId(classname));
if (attrNames)
{
int j;
--- 327,333 ----
tuple = 0;
while (tuple < PQntuples(res))
{
! fprintf(fout, "INSERT INTO %s ", fmtId(classname));
if (attrNames)
{
int j;
***************
*** 338,344 ****
{
if (tblinfo.inhAttrs[j] == 0)
{
! sprintf(q, "%s%s\"%s\"",
q,
(actual_atts > 0) ? "," : "",
fmtId(tblinfo.attnames[j]));
--- 338,344 ----
{
if (tblinfo.inhAttrs[j] == 0)
{
! sprintf(q, "%s%s%s",
q,
(actual_atts > 0) ? "," : "",
fmtId(tblinfo.attnames[j]));
***************
*** 1570,1576 ****
exit_nicely(g_conn);
}
tgfunc = finfo[findx].proname;
! sprintf(query, "CREATE TRIGGER \"%s\" ", PQgetvalue(res2, i2, i_tgname));
/* Trigger type */
findx = 0;
if (TRIGGER_FOR_BEFORE(tgtype))
--- 1570,1576 ----
exit_nicely(g_conn);
}
tgfunc = finfo[findx].proname;
! sprintf(query, "CREATE TRIGGER %s ", fmtId(PQgetvalue(res2, i2, i_tgname)));
/* Trigger type */
findx = 0;
if (TRIGGER_FOR_BEFORE(tgtype))
***************
*** 1597,1604 ****
else
strcat(query, " UPDATE");
}
! sprintf(query, "%s ON \"%s\" FOR EACH ROW EXECUTE PROCEDURE %s (",
! query, tblinfo[i].relname, tgfunc);
for (findx = 0; findx < tgnargs; findx++)
{
char *s,
--- 1597,1604 ----
else
strcat(query, " UPDATE");
}
! sprintf(query, "%s ON %s FOR EACH ROW EXECUTE PROCEDURE %s (",
! query, fmtId(tblinfo[i].relname), tgfunc);
for (findx = 0; findx < tgnargs; findx++)
{
char *s,
***************
*** 1967,1976 ****
becomeUser(fout, tinfo[i].usename);
sprintf(q,
! "CREATE TYPE \"%s\" "
"( internallength = %s, externallength = %s, input = %s, "
"output = %s, send = %s, receive = %s, default = '%s'",
! tinfo[i].typname,
tinfo[i].typlen,
tinfo[i].typprtlen,
tinfo[i].typinput,
--- 1967,1976 ----
becomeUser(fout, tinfo[i].usename);
sprintf(q,
! "CREATE TYPE %s "
"( internallength = %s, externallength = %s, input = %s, "
"output = %s, send = %s, receive = %s, default = '%s'",
! fmtId(tinfo[i].typname),
tinfo[i].typlen,
tinfo[i].typprtlen,
tinfo[i].typinput,
***************
*** 2033,2045 ****
becomeUser(fout, finfo[i].usename);
! sprintf(q, "CREATE FUNCTION \"%s\" (", finfo[i].proname);
for (j = 0; j < finfo[i].nargs; j++)
{
char *typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j]);
! sprintf(q, "%s%s\"%s\"",
q,
(j > 0) ? "," : "",
fmtId(typname));
--- 2033,2045 ----
becomeUser(fout, finfo[i].usename);
! sprintf(q, "CREATE FUNCTION %s (", fmtId(finfo[i].proname));
for (j = 0; j < finfo[i].nargs; j++)
{
char *typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j]);
! sprintf(q, "%s%s%s",
q,
(j > 0) ? "," : "",
fmtId(typname));
***************
*** 2400,2407 ****
/* Revoke Default permissions for PUBLIC */
fprintf(fout,
! "REVOKE ALL on \"%s\" from PUBLIC;\n",
! tbinfo.relname);
for (k = 0; k < l; k++)
{
--- 2400,2407 ----
/* Revoke Default permissions for PUBLIC */
fprintf(fout,
! "REVOKE ALL on %s from PUBLIC;\n",
! fmtId(tbinfo.relname));
for (k = 0; k < l; k++)
{
***************
*** 2409,2421 ****
{
if (ACLlist[k].user == (char *) NULL)
fprintf(fout,
! "GRANT %s on \"%s\" to PUBLIC;\n",
! ACLlist[k].privledges, tbinfo.relname);
else
fprintf(fout,
! "GRANT %s on \"%s\" to \"%s\";\n",
! ACLlist[k].privledges, tbinfo.relname,
! ACLlist[k].user);
}
}
}
--- 2409,2421 ----
{
if (ACLlist[k].user == (char *) NULL)
fprintf(fout,
! "GRANT %s on %s to PUBLIC;\n",
! ACLlist[k].privledges, fmtId(tbinfo.relname));
else
fprintf(fout,
! "GRANT %s on %s to %s;\n",
! ACLlist[k].privledges, fmtId(tbinfo.relname),
! fmtId(ACLlist[k].user));
}
}
}
***************
*** 2471,2477 ****
becomeUser(fout, tblinfo[i].usename);
! sprintf(q, "CREATE TABLE \"%s\" (", fmtId(tblinfo[i].relname));
actual_atts = 0;
for (j = 0; j < tblinfo[i].numatts; j++)
{
--- 2471,2477 ----
becomeUser(fout, tblinfo[i].usename);
! sprintf(q, "CREATE TABLE %s (", fmtId(tblinfo[i].relname));
actual_atts = 0;
for (j = 0; j < tblinfo[i].numatts; j++)
{
***************
*** 2481,2487 ****
/* Show lengths on bpchar and varchar */
if (!strcmp(tblinfo[i].typnames[j], "bpchar"))
{
! sprintf(q, "%s%s\"%s\" char",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]));
--- 2481,2487 ----
/* Show lengths on bpchar and varchar */
if (!strcmp(tblinfo[i].typnames[j], "bpchar"))
{
! sprintf(q, "%s%s%s char",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]));
***************
*** 2493,2499 ****
}
else if (!strcmp(tblinfo[i].typnames[j], "varchar"))
{
! sprintf(q, "%s%s\"%s\" %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
--- 2493,2499 ----
}
else if (!strcmp(tblinfo[i].typnames[j], "varchar"))
{
! sprintf(q, "%s%s%s %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
***************
*** 2506,2512 ****
}
else
{
! sprintf(q, "%s%s\"%s\" %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
--- 2506,2512 ----
}
else
{
! sprintf(q, "%s%s%s %s",
q,
(actual_atts > 0) ? ", " : "",
fmtId(tblinfo[i].attnames[j]),
***************
*** 2539,2545 ****
sprintf(q, "%s%s%s",
q,
(k > 0) ? ", " : "",
! parentRels[k]);
}
strcat(q, ")");
}
--- 2539,2545 ----
sprintf(q, "%s%s%s",
q,
(k > 0) ? ", " : "",
! fmtId(parentRels[k]));
}
strcat(q, ")");
}
***************
*** 2648,2654 ****
else
attname = tblinfo[tableInd].attnames[indkey];
if (funcname)
! sprintf(attlist + strlen(attlist), "%s\"%s\"",
(k == 0) ? "" : ", ", fmtId(attname));
else
{
--- 2648,2654 ----
else
attname = tblinfo[tableInd].attnames[indkey];
if (funcname)
! sprintf(attlist + strlen(attlist), "%s%s",
(k == 0) ? "" : ", ", fmtId(attname));
else
{
***************
*** 2659,2665 ****
attname, indinfo[i].indexrelname);
exit_nicely(g_conn);
}
! sprintf(attlist + strlen(attlist), "%s\"%s\" \"%s\"",
(k == 0) ? "" : ", ", fmtId(attname), fmtId(classname[k]));
free(classname[k]);
}
--- 2659,2665 ----
attname, indinfo[i].indexrelname);
exit_nicely(g_conn);
}
! sprintf(attlist + strlen(attlist), "%s%s %s",
(k == 0) ? "" : ", ", fmtId(attname), fmtId(classname[k]));
free(classname[k]);
}
***************
*** 2668,2681 ****
if (!tablename || (!strcmp(indinfo[i].indrelname, tablename)))
{
! sprintf(q, "CREATE %s INDEX \"%s\" on \"%s\" using %s (",
(strcmp(indinfo[i].indisunique, "t") == 0) ? "UNIQUE" : "",
fmtId(indinfo[i].indexrelname),
fmtId(indinfo[i].indrelname),
indinfo[i].indamname);
if (funcname)
{
! sprintf(q, "%s %s (%s) \"%s\" );\n",
q, funcname, attlist, fmtId(classname[0]));
free(funcname);
free(classname[0]);
--- 2668,2681 ----
if (!tablename || (!strcmp(indinfo[i].indrelname, tablename)))
{
! sprintf(q, "CREATE %s INDEX %s on %s using %s (",
(strcmp(indinfo[i].indisunique, "t") == 0) ? "UNIQUE" : "",
fmtId(indinfo[i].indexrelname),
fmtId(indinfo[i].indrelname),
indinfo[i].indamname);
if (funcname)
{
! sprintf(q, "%s %s (%s) %s );\n",
q, funcname, attlist, fmtId(classname[0]));
free(funcname);
free(classname[0]);
***************
*** 2892,2898 ****
sprintf(query,
"SELECT sequence_name, last_value, increment_by, max_value, "
! "min_value, cache_value, is_cycled, is_called from \"%s\"",
fmtId(tbinfo.relname));
res = PQexec(g_conn, query);
--- 2892,2898 ----
sprintf(query,
"SELECT sequence_name, last_value, increment_by, max_value, "
! "min_value, cache_value, is_cycled, is_called from %s",
fmtId(tbinfo.relname));
res = PQexec(g_conn, query);
***************
*** 2931,2937 ****
PQclear(res);
sprintf(query,
! "CREATE SEQUENCE \"%s\" start %d increment %d maxvalue %d "
"minvalue %d cache %d %s;\n",
fmtId(tbinfo.relname), last, incby, maxv, minv, cache,
(cycled == 't') ? "cycle" : "");
--- 2931,2937 ----
PQclear(res);
sprintf(query,
! "CREATE SEQUENCE %s start %d increment %d maxvalue %d "
"minvalue %d cache %d %s;\n",
fmtId(tbinfo.relname), last, incby, maxv, minv, cache,
(cycled == 't') ? "cycle" : "");
> > > 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
> > > > 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)
> 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)
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
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
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
> > > 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)
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
> > > 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)
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
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
> 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)
> > 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