Thread: TODO list check
My last run-through before the apocalypse ... * Disallow inherited columns with the same name as new columns Either this was just not marked off, or there is some misconception about how things should work. E.g., create table a (x int); create table b (x text) inherits (a); will fail, for obvious reasons. create table a (x int); create table b (x int) inherits (a); will not fail, but will create a table b with *one* column x which is the one inherited from a. This might be confusing in this context, but what about create table a (x int); create table b (y text) inherits (a); create table c (z text) inherits (a); create table d (q time) inherits (b, c); In this case you must allow this "column merging" to happen, otherwise this whole scheme of inheriting would be impossible. So either the above item seems done or we prohibit multiple inheritance. * Do not allow bpchar column creation without length peter=> create table foo (a bpchar); CREATE peter=> \d foo Table "foo"Attribute | Type | Extra -----------+---------+-------a | char(1) | Looks good to me (and is standard compliant). * Update table SET table.value = 3 fails(SQL standard says this is OK) We agreed that this was definitely not okay by any standard we know of. Please remove it. * SELECT ... UNION ... ORDER BY fails when sort expr not in result list Looks good to me: peter=> select * from test1;a | b ---+----1 | 112 | 22 (2 rows) peter=> select * from test2;a | b ---+----3 | 334 | 44 (2 rows) peter=> select a from test1 union select a from test2 order by b;a ---1234 (4 rows) Perhaps be more specific? * SELECT ... UNION ... GROUP BY fails if column types disagree Shouldn't it? * Allow user to define char1 column Both of create table test (a char); create table test (a char(1)); seem to work. * Add support for & operator To do what? I can only see this specified in embedded SQL. More specific here as well? * Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports This is done. * Make type equivalency apply to aggregates This is done. * -Add ALTER TABLE DROP/ALTER COLUMN feature Ain't gonna happen. (Okay, the ALTER COLUMN part is, but not the rest.) * Add PL/Perl(Mark Hollomon) I understand this is done as well. Someone might want to incorporate this into the build process, as well as add it into createlang. * Pre-generate lex and yacc output so not required for install Done. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> My last run-through before the apocalypse ...
Actually, I believe the core decided to postpone 7.0 beta to ~ Feb 15
a day or two ago during an IRC chat. Thomas isn't ready, and it seems
like everyone else could use a little more time too. Marc was supposed
to send out a notification to pg-hackers, but I haven't seen it go by...
> * Disallow inherited columns with the same name as new columns
> Either this was just not marked off, or there is some misconception about
> how things should work.
Well, I'm not sure. Clearly, multiple inheritance is a problem if you
can't inherit similar columns from two parents. But is it a good idea
to allow a child to declare (what it thinks is) a new column, and have
that silently get merged with an inherited column? Seems like kicking
out an error would be a better idea.
> * Do not allow bpchar column creation without length
> Looks good to me (and is standard compliant).
I don't see a good reason for this item either.
> * SELECT ... UNION ... ORDER BY fails when sort expr not in result list
> Looks good to me:
No, it's still broken; your test case doesn't actually exercise any
sorting, does it? The bug is that the ORDER BY only gets applied to the
first SELECT; the rest are just appended on. This bug is awaiting
querytree redesign; it's possible that it could be fixed now, but the
UNION code is so bogus that no one really wants to touch it now...
> * SELECT ... UNION ... GROUP BY fails if column types disagree
> Shouldn't it?
Not if they can be promoted to a common supertype. The entry is pretty
misleading because it is so terse though. The system *does* in fact
promote to a common supertype, it's the GROUP BY part that is at risk.
My note about this readsselect q1 from int8_tbl union select f1 from int4_tbl group by f1;fails (subtly) because wrong
sortopis applied to f1.
Examining the parsetree shows that int4lt is applied to sort f1 (for
grouping) *after* it is promoted to int8. Oops. Again, this is
probably very difficult to fix without parsetree restructuring.
> * Allow user to define char1 column
> Both of
> create table test (a char);
> create table test (a char(1));
> seem to work.
The problem is that you can't any longer get at the plain "char"
datatype, which is not to be confused with bpchar(1). If you just want
a one-byte datatype, say for a poor man's enumerated type ('A' =
something, 'B' = something else, etc), you can't have it. bpchar(1)
acts the same but actually occupies 5 to 8 bytes :-(. True "char" is
still used in several system tables, there's just no good way for users
to get at it. I think the proposal was to rename it "char1" so that it
could be accessed.
Come to think of it, it was mostly me complaining about this, so maybe
I should just go do it; no time for it like 7.0, no? Will anyone object
if I do this?
> * Add support for & operator
> To do what?
I don't know what this is about either.
regards, tom lane
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > My last run-through before the apocalypse ... > > > * Disallow inherited columns with the same name as new columns > > Either this was just not marked off, or there is some misconception about > how things should work. E.g., > create table a (x int); > create table b (x text) inherits (a); > will fail, for obvious reasons. > > create table a (x int); > create table b (x int) inherits (a); > will not fail, but will create a table b with *one* column x which is the > one inherited from a. This might be confusing in this context, but what > about > > create table a (x int); > create table b (y text) inherits (a); > create table c (z text) inherits (a); > create table d (q time) inherits (b, c); > > In this case you must allow this "column merging" to happen, otherwise > this whole scheme of inheriting would be impossible. So either the above > item seems done or we prohibit multiple inheritance. Removed. > > > * Do not allow bpchar column creation without length > > peter=> create table foo (a bpchar); > CREATE > peter=> \d foo > Table "foo" > Attribute | Type | Extra > -----------+---------+------- > a | char(1) | > > Looks good to me (and is standard compliant). Removed. > > > * Update table SET table.value = 3 fails(SQL standard says this is OK) > > We agreed that this was definitely not okay by any standard we know of. > Please remove it. Removed. > > > * SELECT ... UNION ... ORDER BY fails when sort expr not in result list > > Looks good to me: > > peter=> select * from test1; > a | b > ---+---- > 1 | 11 > 2 | 22 > (2 rows) > > peter=> select * from test2; > a | b > ---+---- > 3 | 33 > 4 | 44 > (2 rows) > > peter=> select a from test1 union select a from test2 order by b; > a > --- > 1 > 2 > 3 > 4 > (4 rows) > > Perhaps be more specific? > Removed. > > * SELECT ... UNION ... GROUP BY fails if column types disagree > > Shouldn't it? > Removed. > > * Allow user to define char1 column > > Both of > create table test (a char); > create table test (a char(1)); > seem to work. > Marked as done. > > * Add support for & operator > > To do what? I can only see this specified in embedded SQL. More specific > here as well? They want to use it for some bitwise stuff. I think we have a bit type somewhere. > > > * Make Absolutetime/Relativetime int4 because time_t can be int8 on some > ports > > This is done. Marked as done. I think your copy is a little old because dash marks appear on my copy. > > > * Make type equivalency apply to aggregates > > This is done. > Already marked. > > * -Add ALTER TABLE DROP/ALTER COLUMN feature > > Ain't gonna happen. (Okay, the ALTER COLUMN part is, but not the rest.) > I understand, and think it is a shame. > > * Add PL/Perl(Mark Hollomon) > > I understand this is done as well. Someone might want to incorporate this > into the build process, as well as add it into createlang. Marked as done. > > > * Pre-generate lex and yacc output so not required for install > > Done. Marked as done. Thanks for the updates. -- Bruce Momjian | http://www.op.net/~candle pgman@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
> Peter Eisentraut <peter_e@gmx.net> writes:
> > My last run-through before the apocalypse ...
>
> Actually, I believe the core decided to postpone 7.0 beta to ~ Feb 15
> a day or two ago during an IRC chat. Thomas isn't ready, and it seems
> like everyone else could use a little more time too. Marc was supposed
> to send out a notification to pg-hackers, but I haven't seen it go by...
>
>
> > * Disallow inherited columns with the same name as new columns
>
> > Either this was just not marked off, or there is some misconception about
> > how things should work.
Re-added.
>
> Well, I'm not sure. Clearly, multiple inheritance is a problem if you
> can't inherit similar columns from two parents. But is it a good idea
> to allow a child to declare (what it thinks is) a new column, and have
> that silently get merged with an inherited column? Seems like kicking
> out an error would be a better idea.
>
> > * Do not allow bpchar column creation without length
>
> > Looks good to me (and is standard compliant).
>
> I don't see a good reason for this item either.
>
> > * SELECT ... UNION ... ORDER BY fails when sort expr not in result list
>
> > Looks good to me:
Re-added.
>
> No, it's still broken; your test case doesn't actually exercise any
> sorting, does it? The bug is that the ORDER BY only gets applied to the
> first SELECT; the rest are just appended on. This bug is awaiting
> querytree redesign; it's possible that it could be fixed now, but the
> UNION code is so bogus that no one really wants to touch it now...
>
> > * SELECT ... UNION ... GROUP BY fails if column types disagree
>
> > Shouldn't it?
Re-added.
>
> Not if they can be promoted to a common supertype. The entry is pretty
> misleading because it is so terse though. The system *does* in fact
> promote to a common supertype, it's the GROUP BY part that is at risk.
> My note about this reads
> select q1 from int8_tbl union select f1 from int4_tbl group by f1;
> fails (subtly) because wrong sortop is applied to f1.
> Examining the parsetree shows that int4lt is applied to sort f1 (for
> grouping) *after* it is promoted to int8. Oops. Again, this is
> probably very difficult to fix without parsetree restructuring.
>
> > * Allow user to define char1 column
>
> > Both of
> > create table test (a char);
> > create table test (a char(1));
> > seem to work.
Re-added.
>
> The problem is that you can't any longer get at the plain "char"
> datatype, which is not to be confused with bpchar(1). If you just want
> a one-byte datatype, say for a poor man's enumerated type ('A' =
> something, 'B' = something else, etc), you can't have it. bpchar(1)
> acts the same but actually occupies 5 to 8 bytes :-(. True "char" is
> still used in several system tables, there's just no good way for users
> to get at it. I think the proposal was to rename it "char1" so that it
> could be accessed.
>
> Come to think of it, it was mostly me complaining about this, so maybe
> I should just go do it; no time for it like 7.0, no? Will anyone object
> if I do this?
>
> > * Add support for & operator
>
> > To do what?
>
> I don't know what this is about either.
>
> regards, tom lane
>
> ************
>
-- Bruce Momjian | http://www.op.net/~candle pgman@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
Has anybody had any opinions on getting rid of the "*" syntax like Informix/Illustra has done? In other words in postgres, this... SELECT * FROM person* would be in Informix SELECT * FROM person and in postgres... SELECT * FROM person would be in Informix... SELECT * FROM ONLY person I think it makes a lot more sense. Any intellectual support for that in some future release?
Chris Bitmead <chris@bitmead.com> writes:
> Has anybody had any opinions on getting rid of the "*" syntax like
> Informix/Illustra has done?
I think that on an abstract OODB level they did the right thing.
The only argument against changing would be if it breaks the
existing code for too many applications. pghackers is probably
not the best place to get a sense of that --- maybe you should
bring up the point on pgsql-sql (and perhaps pgsql-general?)
regards, tom lane
On 2000-01-27, Tom Lane mentioned: > > * Disallow inherited columns with the same name as new columns > > > Either this was just not marked off, or there is some misconception about > > how things should work. > > Well, I'm not sure. Clearly, multiple inheritance is a problem if you > can't inherit similar columns from two parents. But is it a good idea > to allow a child to declare (what it thinks is) a new column, and have > that silently get merged with an inherited column? Seems like kicking > out an error would be a better idea. Okay, now it gives an error if you try to create a new column with the same name as an inherited column, but allows merging of columns between inherited tables. Check. > > * SELECT ... UNION ... ORDER BY fails when sort expr not in result list > > > Looks good to me: > > No, it's still broken; your test case doesn't actually exercise any > sorting, does it? The bug is that the ORDER BY only gets applied to the > first SELECT; the rest are just appended on. This bug is awaiting > querytree redesign; it's possible that it could be fixed now, but the > UNION code is so bogus that no one really wants to touch it now... > > > * SELECT ... UNION ... GROUP BY fails if column types disagree > > > Shouldn't it? > > Not if they can be promoted to a common supertype. The entry is pretty > misleading because it is so terse though. How about adding this into TODO.detail, so two months from now everyone (except those that keep outside lists) remembers it. (Or just rephrase this item, if you can.) > > * Do not allow bpchar column creation without length > > > Looks good to me (and is standard compliant). > > I don't see a good reason for this item either. This item may be the same as the one below. The other day while working on psql and mapping internal to sql types for \d output I noticed that system tables have char columns with -1 typmod. I suppose that this would be your char1 type? > > * Allow user to define char1 column > Come to think of it, it was mostly me complaining about this, so maybe > I should just go do it; no time for it like 7.0, no? Will anyone object > if I do this? At least the above behaviour is very subtle indeed. While I'm not so excited about having all kinds of "more efficient" types around for internal use (char1, abstime, some of the oid arrays), do what you feel is best. The clean solution would seem to be item * Allow char() not to use variable-sized header to reduce disk size where you would use the atttypmod as the length instead of the header. But a general solution like this would probably require too many structural changes. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> The clean solution would seem to be item
> * Allow char() not to use variable-sized header to reduce disk size
> where you would use the atttypmod as the length instead of the header. But
> a general solution like this would probably require too many structural
> changes.
Right now, *all* variable-length types have a varlena header, and
I think there isn't much of any way around that for internal
representation --- if Datums aren't self-sufficient then we've got
a real notational nightmare in the expression evaluator and function
call mechanism. Maybe we could make the inside-a-tuple representation
different from what gets passed around in expression evaluation, but
that sure looks like a can of worms to me. So I don't foresee this
TODO item getting done any time soon --- the cost/benefit ratio looks
way too high compared to all our other projects.
The reason the "allow access to char1" item is there is that I have an
application that has several different status indicators in each row
of a large table. I represented them as "char" values, which was both
useful for debugging ('P' = pending, etc) and compact, or so I thought.
When I realized that my status fields were not taking one byte apiece
as I expected, but eight bytes apiece (length word + alignment), I
wasn't happy.
We are using char1 as an enumerated type in several system fields
(relkind, for example) so I see no good reason why that type shouldn't
be available to user applications. It is actually possible to *make*
a char1 field in a user table:create table t1 (f1 "char");
but pg_dump won't reliably dump and restore this declaration because
it depends on a quoting hack not to be rewritten as bpchar(1) by the
parser.
regards, tom lane
TODO list updated with your suggestions. [Charset ISO-8859-1 unsupported, filtering to ASCII...] > On 2000-01-27, Tom Lane mentioned: > > > > * Disallow inherited columns with the same name as new columns > > > > > Either this was just not marked off, or there is some misconception about > > > how things should work. > > > > Well, I'm not sure. Clearly, multiple inheritance is a problem if you > > can't inherit similar columns from two parents. But is it a good idea > > to allow a child to declare (what it thinks is) a new column, and have > > that silently get merged with an inherited column? Seems like kicking > > out an error would be a better idea. > > Okay, now it gives an error if you try to create a new column with the > same name as an inherited column, but allows merging of columns between > inherited tables. Check. > > > > > * SELECT ... UNION ... ORDER BY fails when sort expr not in result list > > > > > Looks good to me: > > > > No, it's still broken; your test case doesn't actually exercise any > > sorting, does it? The bug is that the ORDER BY only gets applied to the > > first SELECT; the rest are just appended on. This bug is awaiting > > querytree redesign; it's possible that it could be fixed now, but the > > UNION code is so bogus that no one really wants to touch it now... > > > > > * SELECT ... UNION ... GROUP BY fails if column types disagree > > > > > Shouldn't it? > > > > Not if they can be promoted to a common supertype. The entry is pretty > > misleading because it is so terse though. > > How about adding this into TODO.detail, so two months from now everyone > (except those that keep outside lists) remembers it. (Or just rephrase > this item, if you can.) > > > > > * Do not allow bpchar column creation without length > > > > > Looks good to me (and is standard compliant). > > > > I don't see a good reason for this item either. > > This item may be the same as the one below. The other day while working on > psql and mapping internal to sql types for \d output I noticed that system > tables have char columns with -1 typmod. I suppose that this would be your > char1 type? > > > > * Allow user to define char1 column > > > Come to think of it, it was mostly me complaining about this, so maybe > > I should just go do it; no time for it like 7.0, no? Will anyone object > > if I do this? > > At least the above behaviour is very subtle indeed. While I'm not so > excited about having all kinds of "more efficient" types around for > internal use (char1, abstime, some of the oid arrays), do what you feel is > best. The clean solution would seem to be item > > * Allow char() not to use variable-sized header to reduce disk size > > where you would use the atttypmod as the length instead of the header. But > a general solution like this would probably require too many structural > changes. > > > -- > Peter Eisentraut Sernanders v_g 10:115 > peter_e@gmx.net 75262 Uppsala > http://yi.org/peter-e/ Sweden > > > > ************ > -- Bruce Momjian | http://www.op.net/~candle pgman@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