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 | 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?


* 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


Thu, 27 Jan 2000 23:28:44 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
TODO list check
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 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.

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

Thu, 27 Jan 2000 19:05:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] TODO list check 
[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, Pennsylvania 19026

Thu, 27 Jan 2000 22:46:53 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list check
> 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, Pennsylvania 19026

Thu, 27 Jan 2000 23:46:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list check

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?

Fri, 28 Jan 2000 16:18:47 +1100
Chris Bitmead <chris@bitmead.com>
ONLY vs "*"
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

Fri, 28 Jan 2000 01:24:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] ONLY vs "*" 
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



Sat, 29 Jan 2000 12:14:01 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] TODO list check 
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

Sat, 29 Jan 2000 10:58:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] TODO list check 

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, Pennsylvania 19026

Sat, 29 Jan 2000 12:23:45 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list check