Open 6.5 items
SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error
Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
When creating a table with either type inet or type cidr as a primary,unique
key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equal
Make sure pg_internal.init concurrent generation can't cause unreliability
ALTER TABLE ADD COLUMN to inherited table put column in wrong place
crypt_loadpwdfile() is mixing and (mis)matching memory allocation
protocols, trying to use pfree() to release pwd_cache vector from realloc()
3 = sum(x) in rewrite system is a problem
Fix function pointer calls to take Datum args for char and int2 args(ecgs)
Do we want pg_dump -z to be the default?
pg_dump of groups fails
pg_dump -o -D does not work, and can not work currently, generate error?
psql \d should show precision
dumping out sequences should not be counted in pg_dump display
Make psql \help, man pages, and sgml reflect changes in grammar
Markup sql.sgml, Stefan's intro to SQL
Markup cvs.sgml, cvs and cvsup howto
Add figures to sql.sgml and arch-dev.sgml, both from Stefan
Include Jose's date/time history in User's Guide (neat!)
Generate Admin, User, Programmer hardcopy postscript
Future TODO items
-----------------
Make Serial its own type
Add support for & operator
store binary-compatible type information in the system somewhere
add ability to add comments to system tables using table/colname combination
process const=const parts of OR clause in separate pass
make oid use oidin/oidout not int4in/int4out in pg_type.h, make oid use
unsigned int more reliably, pg_atoi()
CREATE VIEW ignores DISTINCT
Move LIKE index optimization handling to the optimizer?
Allow ESCAPE '\' at the end of LIKE for ANSI compliance, or rewrite the
LIKE handling by rewriting the user string with the supplied ESCAPE
Fix leak for expressions?, aggregates?
Improve LIMIT processing by using index to limit rows processed
CLUSTER failure if vacuum has not been performed in a while
CREATE OPERATOR *= (leftarg=_varchar, rightarg=varchar,
procedure=array_varchareq); fails, varchar is reserved word, quotes work
Improve Subplan list handling
Allow Subplans to use efficient joins(hash, merge) with upper variable
Update reltuples from COPY command
CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops) fails
index can't store constant parameters, allow SQL function indexes?
Improve NULL parameter passing into functions
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Thus spake Bruce Momjian
Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
Is that an error? From the discussions with Paul Vixie, I think that
that is the correct way to output it. Note that you can always use
host() to get the full string for the host part at least.
When creating a table with either type inet or type cidr as a primary,unique
key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equal
I guess I'll take a stab at it. I just need to know which of the following
is true.
198.68.123.0/24 < 198.68.123.0/27
198.68.123.0/24 > 198.68.123.0/27
Also, is it possible that the current behaviour is what we want? It seems
to me that if you make a network a primary key, you probably want to prevent
overlap. What we have does that.
add ability to add comments to system tables using table/colname combination
Why not just add comments to pg_description?
--
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.Thus spake Bruce Momjian
Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
Is that an error? From the discussions with Paul Vixie, I think that
that is the correct way to output it. Note that you can always use
host() to get the full string for the host part at least.
Well, if you say it OK, that's good enough for me. Item removed. It
just looked strange, the 00/0. Can you explain why it should look like
that. Just curious.
When creating a table with either type inet or type cidr as a primary,unique
key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equalI guess I'll take a stab at it. I just need to know which of the following
is true.198.68.123.0/24 < 198.68.123.0/27
198.68.123.0/24 > 198.68.123.0/27Also, is it possible that the current behaviour is what we want? It seems
to me that if you make a network a primary key, you probably want to prevent
overlap. What we have does that.
Good question. If we decide the current behaviour is OK, that is fine
with me. Someone know understand this just needs to say so.
add ability to add comments to system tables using table/colname combination
Why not just add comments to pg_description?
Adding to pg_description requires table creation, then oid retrieval,
then inserts into pg_description. At one time, I toyed with the idea of
making this more automatic, but obviously at this point, I will just
add it into the TODO list, if is not there already.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Thus spake Bruce Momjian
Thus spake Bruce Momjian
Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
Is that an error? From the discussions with Paul Vixie, I think that
that is the correct way to output it. Note that you can always use
host() to get the full string for the host part at least.Well, if you say it OK, that's good enough for me. Item removed. It
just looked strange, the 00/0. Can you explain why it should look like
that. Just curious.
I'm not sure why "00/0" rather than "0/0" but basically you don't have
to show more octets than necessary based on the netmask. For example,
a netmask of 32 bits requires all 4, 24 bits requires 3, 16 needs 2
and 8 (and less) needs 1. Technically you don't even need 1 octet for
0 bits I suppose but "/0" doesn't make much sense.
This is all based on my understanding. RFC lawyers, please feel free to
correct me.
When creating a table with either type inet or type cidr as a primary,unique
key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equalI guess I'll take a stab at it. I just need to know which of the following
is true.198.68.123.0/24 < 198.68.123.0/27
198.68.123.0/24 > 198.68.123.0/27Also, is it possible that the current behaviour is what we want? It seems
to me that if you make a network a primary key, you probably want to prevent
overlap. What we have does that.Good question. If we decide the current behaviour is OK, that is fine
with me. Someone know understand this just needs to say so.
And if not, what is the answer to the above question.
--
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.I'm not sure why "00/0" rather than "0/0" but basically you don't have
to show more octets than necessary based on the netmask. For example,
a netmask of 32 bits requires all 4, 24 bits requires 3, 16 needs 2
and 8 (and less) needs 1. Technically you don't even need 1 octet for
0 bits I suppose but "/0" doesn't make much sense.
Well, then it is a bug. It should show 00/0.
This is all based on my understanding. RFC lawyers, please feel free to
correct me.When creating a table with either type inet or type cidr as a primary,unique
key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equalI guess I'll take a stab at it. I just need to know which of the following
is true.198.68.123.0/24 < 198.68.123.0/27
198.68.123.0/24 > 198.68.123.0/27Also, is it possible that the current behaviour is what we want? It seems
to me that if you make a network a primary key, you probably want to prevent
overlap. What we have does that.Good question. If we decide the current behaviour is OK, that is fine
with me. Someone know understand this just needs to say so.And if not, what is the answer to the above question.
Don't know.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026