Thread: open 6.4 items
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
foreign key?(Vadim)
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
fix problem when DEFAULT string for CHAR() is not same as column
have psql dump out rules text with new function
cnf-ify still can exhaust memory
permissions on indexes: what do they do? should it be prevented?
man pages/sgml synchronization (dump out man pages as postscript?)
remove PARSEDEBUG defines if not longer needed
low level locking - status?
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chainging of pages to allow >8k tuples
SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
--
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)
> fix problem when DEFAULT string for CHAR() is not same as column
I think I fixed that a while ago. I've forgotten which file was
involved, but I no longer see the symptom on my system.
> man pages/sgml synchronization (dump out man pages as postscript?)
We should synchronize the man pages and sgml for this release, if
possible, and then commit to using the sgml sources for man pages for
v6.5. After v6.4 is released, man pages (but not sgml) are frozen until
they can be generated from the sgml.
> remove PARSEDEBUG defines if not longer needed
OK. You really want those gone, don't you!
> use index with constants on functions
Not likely for v6.4. On my list for v6.5.
> SELECT oid @ oid @ oid FROM pg_user fails with parser error, not
> function error
What is the issue with this? The parser doesn't know how to group the
arguments and operators, so barfs. The only operators which have
explicit precedence are the plain standard ones (+,-,*,/ for math and
=,<,> for comparisons, and |,: for who-knows-what). Everything else
falls into the same precedence, higher than the comparison operators and
lower than the math ones. This includes, for example, "<=" which should
be the same precedence as the other comparison ops, but has higher
precedence at the moment.
> no min/max for oid type
Does this still need to be on the list? The guy who asked for it
actually needed something else...
- Tom
> > fix problem when DEFAULT string for CHAR() is not same as column > > I think I fixed that a while ago. I've forgotten which file was > involved, but I no longer see the symptom on my system. Removed. > > > man pages/sgml synchronization (dump out man pages as postscript?) > > We should synchronize the man pages and sgml for this release, if > possible, and then commit to using the sgml sources for man pages for > v6.5. After v6.4 is released, man pages (but not sgml) are frozen until > they can be generated from the sgml. OK. > > > remove PARSEDEBUG defines if not longer needed > > OK. You really want those gone, don't you! I can move it to the TODO list, OK? :-) > > > use index with constants on functions > > Not likely for v6.4. On my list for v6.5. OK. > > > SELECT oid @ oid @ oid FROM pg_user fails with parser error, not > > function error > > What is the issue with this? The parser doesn't know how to group the > arguments and operators, so barfs. The only operators which have > explicit precedence are the plain standard ones (+,-,*,/ for math and > =,<,> for comparisons, and |,: for who-knows-what). Everything else > falls into the same precedence, higher than the comparison operators and > lower than the math ones. This includes, for example, "<=" which should > be the same precedence as the other comparison ops, but has higher > precedence at the moment. Should I move this to the TODO list now? > > > no min/max for oid type > > Does this still need to be on the list? The guy who asked for it > actually needed something else... I can move some of the items off now, rather than wait until just before 6.4 to be released to move them. OK? -- 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 Thu, 10 Sep 1998, Bruce Momjian wrote:
> large objects orphanage
I thought we were in beta?
I didn't have this ready in time for the beta, so I thought it wasn't
going to get in to 6.4.
There isn't much more to do for it though. I'm just finishing off the
documentation for JDBC at the moment, so I can return to it shortly.
--
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
> > > remove PARSEDEBUG defines if not longer needed
> > OK. You really want those gone, don't you!
> I can move it to the TODO list, OK? :-)
No, leave it on the v6.4 FixIt list. This is the start of that list,
right?
> > > SELECT oid @ oid @ oid FROM pg_user fails with parser error, not
> > > function error
> Should I move this to the TODO list now?
Well, I don't know how you would fix it without rewriting the parser or
changing the associativity of generic operators. I would suggest leaving
it off the ToDo list altogether, unless someone can suggest a viable
solution. The example suggests it is a problem with OIDs or with the "@"
operator, not a fundamental feature of the yacc/bison parser.
> > > no min/max for oid type
> I can move some of the items off now, rather than wait until just
> before 6.4 to be released to move them. OK?
Yeah. Let's turn this list into the v6.4 FixIt list; you've done one for
every release I can remember and it has been very helpful.
Be sure to add the views problem to this list ;)
Also, add the html/hardcopy documentation since we will re-release the
User's Guide, Admin Guide, and Programmer's Guide.
- Tom
> Yeah. Let's turn this list into the v6.4 FixIt list; you've done one for
> every release I can remember and it has been very helpful.
The new one.
---------------------------------------------------------------------------
cidr/IP address type(Tom Helbekkmo)
rewrite system(Jan)
foreign key?(Vadim)
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
pg_user dumps core on some platforms
have psql dump out rules text with new function
man pages/sgml synchronization
generate html/postscript documentation
generate postmaster pid file and remove flock/fcntl lock code
cnf-ify still can exhaust memory, make SET KSQO more generic
permissions on indexes: what do they do? should it be prevented?
remove PARSEDEBUG defines if not longer needed
low level locking - work-in-progress for 6.5
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chaining of pages to allow >8k tuples
allow multiple generic operators in expressions without the use of parentheses
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling
no min/max for oid type
--
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)
> foreign key?(Vadim) I just added attributes for primary/unique/foreign keys to pg_index & pg_class => dump/reload (or pg_upgrade)... Nothing more yet, just catalog changes... regression tests ... as usual -:) > > pg_user dumps core on some platforms Please, please - could someone run Purify ? Vadim
Thus spake Vadim Mikheev
> > foreign key?(Vadim)
>
> I just added attributes for primary/unique/foreign keys
> to pg_index & pg_class => dump/reload (or pg_upgrade)...
Hooray!
> Nothing more yet, just catalog changes...
Do you think there would be any problem if I just manually updated those
fields so that I can start testing my Python access stuff? Do they get
set to some default value at least?
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> allow multiple generic operators in expressions without the use of
> parentheses
I could just let this one go until it dies a quiet death, but...
To parse "multiple generic operators", per the example
select oid @ oid @ oid from table;
one would have to change the associativity of many operators from
non-associative (the correct assumption) to left- or right associative
(the wrong thing to do). If we are going to allow operator extensibility
we cannot make assumptions about the precedence order of operators, and
should require parentheses to break the ambiguity.
Unless someone has a good proposal on how to change the standard rules
of arithmetic, or on how to change the parser to allow
operator-dependent precedence in an extensible way, then we shouldn't
bother tracking this as a problem statement imho.
- Tom
D'Arcy J.M. Cain wrote: > > Thus spake Vadim Mikheev > > > foreign key?(Vadim) > > > > I just added attributes for primary/unique/foreign keys > > to pg_index & pg_class => dump/reload (or pg_upgrade)... > > Hooray! > > > Nothing more yet, just catalog changes... > > Do you think there would be any problem if I just manually updated those > fields so that I can start testing my Python access stuff? Do they get > set to some default value at least? No problem. Default is: no keys. Vadim
> > allow multiple generic operators in expressions without the use of > > parentheses > > I could just let this one go until it dies a quiet death, but... > > To parse "multiple generic operators", per the example > > select oid @ oid @ oid from table; > > one would have to change the associativity of many operators from > non-associative (the correct assumption) to left- or right associative > (the wrong thing to do). If we are going to allow operator extensibility > we cannot make assumptions about the precedence order of operators, and > should require parentheses to break the ambiguity. > > Unless someone has a good proposal on how to change the standard rules > of arithmetic, or on how to change the parser to allow > operator-dependent precedence in an extensible way, then we shouldn't > bother tracking this as a problem statement imho. I agree, except the error message returned from the parser is quite confusing, just stating 'parse error'. In fact, it took me 10 minutes to figure out what would and wouldn't work, and I had no idea that parentheses would fix it. If we can't give a better error message, we have to keep it on the todo/bugs list until we can tell people what they are doing wrong, and how to fix it. -- 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)