Обсуждение: 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 vectorfrom 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 useunsigned 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 theLIKE handling by rewriting the user string with thesupplied 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, quoteswork 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) failsindex can't store constant parameters, allowSQL 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, Pennsylvania19026
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 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. 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, Pennsylvania19026
Thus 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 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.
>
> 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 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. > > > > 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, Pennsylvania19026