* User who can create databases can modify pg_database table

Not anymore.

* Interlock to prevent DROP DATABASE on a database with running backends

I think Tom wanted this listed as an achievement, because it's already
done.

* Better interface for adding to pg_group

Done.

* Allow array on int8[]

Done. (Credit to Thomas, thought, he just forgot to apply the patch.)

* Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports

Does this mean the abstime/reltime types or all of them?  I thought the
former were deprecated anyway.

* Permissions on indexes, prevent them?

Done (prevented)

* Make postgres user have a password by default

Done. (--pwprompt option, enter it blind twice, echo ALTER USER |
postgres; probably as secure as it gets)

* Update table SET table.value = 3 fails(SQL standard says this is OK)

Not the standard I'm looking at. Someone please enlighten me.

         <update statement: searched> ::=
           UPDATE <table name>
             SET <set clause list>
               [ WHERE <search condition> ]

         <set clause list> ::=
              <set clause> [ { <comma> <set clause> }... ]

         <set clause> ::=
              <object column> <equals operator> <update source>

         <object column> ::= <column name>

         <column name> ::= <identifier>

         <identifier> ::=
              [ <introducer><character set specification> ] <actual identifier>
  
         <introducer> ::= <underscore>

         <character set specification> ::=
		{ nothing of interest }

         <actual identifier> ::=
                <regular identifier>
              | <delimited identifier>

	{ meaning a non-quoted identifier or a quoted one }


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sat, 15 Jan 2000 19:37:24 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
TODO list
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> * User who can create databases can modify pg_database table
> 
> Not anymore.

Done.  Good.

> 
> * Interlock to prevent DROP DATABASE on a database with running backends
> 
> I think Tom wanted this listed as an achievement, because it's already
> done.

Done.

> 
> * Better interface for adding to pg_group
> 
> Done.

Yes.  I can remove the pg_group FAQ item after 7.0 is out to most
people.

> 
> * Allow array on int8[]
> 
> Done. (Credit to Thomas, thought, he just forgot to apply the patch.)

Good.

> 
> * Make Absolutetime/Relativetime int4 because time_t can be int8 on some
> ports
> 
> Does this mean the abstime/reltime types or all of them?  I thought the
> former were deprecated anyway.

I think the idea is that it can roll over the mac int4 value.  Not sure
about which types are active.


> 
> * Permissions on indexes, prevent them?
> 
> Done (prevented)

Good.


> 
> * Make postgres user have a password by default
> 
> Done. (--pwprompt option, enter it blind twice, echo ALTER USER |
> postgres; probably as secure as it gets)

Perfect.  We don't want to do it by default.

> 
> * Update table SET table.value = 3 fails(SQL standard says this is OK)
> 
> Not the standard I'm looking at. Someone please enlighten me.
> 
>          <update statement: searched> ::=
>            UPDATE <table name>
>              SET <set clause list>
>                [ WHERE <search condition> ]
> 
>          <set clause list> ::=
>               <set clause> [ { <comma> <set clause> }... ]
> 
>          <set clause> ::=
>               <object column> <equals operator> <update source>
> 
>          <object column> ::= <column name>
> 
>          <column name> ::= <identifier>
> 
>          <identifier> ::=
>               [ <introducer><character set specification> ] <actual identifier>
>   
>          <introducer> ::= <underscore>
> 
>          <character set specification> ::=
> 		{ nothing of interest }
> 
>          <actual identifier> ::=
>                 <regular identifier>
>               | <delimited identifier>
> 
> 	{ meaning a non-quoted identifier or a quoted one }
> 

I don't see anything in the spec that says you can use table.column on
the left-hand side of the equals.  No?

-- 
  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, 15 Jan 2000 14:31:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list
At 02:31 PM 1/15/00 -0500, Bruce Momjian wrote:
>> * Update table SET table.value = 3 fails(SQL standard says this is OK)
>> 
>> Not the standard I'm looking at. Someone please enlighten me.

If this is indeed the standard, it looks to me as though Bruce is 
reading it right.  Makes sense, too, only one table can be updated
at a time, so there's no opportunity for ambiguity in column names
on the left side.  What's the point?



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Sat, 15 Jan 2000 11:55:00 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] TODO list
Can we ALTER a table to drop a column yet, or is that still a TO DO item?

Steve


Peter Eisentraut wrote:

> * User who can create databases can modify pg_database table
>
> Not anymore.
>
> * Interlock to prevent DROP DATABASE on a database with running backends
>


Sat, 15 Jan 2000 15:29:50 -0800
Stephen Birch <sbirch@ironmountainsystems.com>
Re: [HACKERS] TODO list
> Can we ALTER a table to drop a column yet, or is that still a TO DO item?
> 

Still a TODO item.
-- 
  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, 15 Jan 2000 21:29:18 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list
I'm working on that, but pssst, don't tell anyone! ;)

On 2000-01-15, Stephen Birch mentioned:

> Can we ALTER a table to drop a column yet, or is that still a TO DO item?
> 
> Steve
> 
> 
> Peter Eisentraut wrote:
> 
> > * User who can create databases can modify pg_database table
> >
> > Not anymore.
> >
> > * Interlock to prevent DROP DATABASE on a database with running backends
> >
> 
> 

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sun, 16 Jan 2000 18:18:31 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] TODO list
> * Allow array on int8[]
> Done. (Credit to Thomas, thought, he just forgot to apply the patch.)

Thanks. btw, didn't forget, but wanted confirmation that it worked
(which I got a day or two later).

> * Make Absolutetime/Relativetime int4 because time_t can be int8 on some
> ports
> Does this mean the abstime/reltime types or all of them?  I thought the
> former were deprecated anyway.

abstime should probably be considered deprecated as a user type, but
it is still used extensively internally and within the tuple
structure. I'd be reluctant to wholesale replace it with
timestamp/datetime, since that will take 8 bytes per value rather than
4.

                       - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 17 Jan 2000 08:02:02 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] TODO list
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Does this mean the abstime/reltime types or all of them?  I thought the
>> former were deprecated anyway.

> abstime should probably be considered deprecated as a user type, but
> it is still used extensively internally and within the tuple
> structure. I'd be reluctant to wholesale replace it with
> timestamp/datetime, since that will take 8 bytes per value rather than
> 4.

I was meaning to ask you which of the date/time types are going to be
left standing when the dust settles.  (I know you've said, but the
archives are so messed up right now that I can't find it.)

Timestamp is the only remaining standard type without an array type,
and if it's not going to be deprecated then it ought to have one...

			regards, tom lane

Mon, 17 Jan 2000 03:08:59 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] TODO list 
> I was meaning to ask you which of the date/time types are going to be
> left standing when the dust settles.  (I know you've said, but the
> archives are so messed up right now that I can't find it.)
> Timestamp is the only remaining standard type without an array type,
> and if it's not going to be deprecated then it ought to have one...

"timestamp" will continue, but *all* of the code will come from a
renamed "datetime". So don't bother adding anything for timestamp,
since it will magically appear when datetime gets renamed.

btw, I will make "datetime" a synonym for "timestamp", so existing
apps should work without change.

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 17 Jan 2000 08:31:52 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] TODO list
On Mon, 17 Jan 2000, Thomas Lockhart wrote:

> > * Make Absolutetime/Relativetime int4 because time_t can be int8 on some
> > ports
> > Does this mean the abstime/reltime types or all of them?  I thought the
> > former were deprecated anyway.
> 
> abstime should probably be considered deprecated as a user type, but
> it is still used extensively internally and within the tuple
> structure. I'd be reluctant to wholesale replace it with
> timestamp/datetime, since that will take 8 bytes per value rather than
> 4.

Just so I understand this: The official SQL data types are "timestamp" and
"interval", right? Everything else will eventually be an alias or phased
out or whatever?

I've been itching to change the pg_shadow.valuntil column to timestamp
anyway, I suppose that would be a step in the right direction, or not?

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Mon, 17 Jan 2000 12:13:35 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] TODO list
> > I was meaning to ask you which of the date/time types are going to be
> > left standing when the dust settles.  (I know you've said, but the
> > archives are so messed up right now that I can't find it.)
> > Timestamp is the only remaining standard type without an array type,
> > and if it's not going to be deprecated then it ought to have one...
> 
> "timestamp" will continue, but *all* of the code will come from a
> renamed "datetime". So don't bother adding anything for timestamp,
> since it will magically appear when datetime gets renamed.
> 
> btw, I will make "datetime" a synonym for "timestamp", so existing
> apps should work without change.

Got it.  Never mind.

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

Mon, 17 Jan 2000 11:17:58 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] TODO list
> The official SQL data types are "timestamp" and
> "interval", right? Everything else will eventually be an alias or 
> phased out or whatever?

No (at least I haven't proposed that). abstime stays as a 4-byte
internal system time type. timestamp and interval become full-featured
date/time types, stealing all of the datetime and timespan code, and
the latter two become synonyms for timestamp and interval.

> I've been itching to change the pg_shadow.valuntil column to timestamp
> anyway, I suppose that would be a step in the right direction, or not?

At the moment, there are *no* 8-byte date/time types in the system
tables. This would be the first instance of that, and I'm not sure we
should introduce it in just one place.

Has abstime been a problem here?

                   - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 17 Jan 2000 16:33:59 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] TODO list
On 2000-01-17, Thomas Lockhart mentioned:

> > The official SQL data types are "timestamp" and
> > "interval", right? Everything else will eventually be an alias or 
> > phased out or whatever?
> 
> No (at least I haven't proposed that). abstime stays as a 4-byte
> internal system time type. timestamp and interval become full-featured
> date/time types, stealing all of the datetime and timespan code, and
> the latter two become synonyms for timestamp and interval.

Okay, so we have "timestamp" and "interval" as offical types, a few
"datetime" sort of things as aliases for backwards compatibility, and
"abstime" as a more or less internal type with less precision and storage
requirements. Sounds clear to me. This also puts the original TODO item
into a much clearer light.

> > I've been itching to change the pg_shadow.valuntil column to timestamp
> > anyway, I suppose that would be a step in the right direction, or not?
> 
> At the moment, there are *no* 8-byte date/time types in the system
> tables. This would be the first instance of that, and I'm not sure we
> should introduce it in just one place.
> 
> Has abstime been a problem here?

No. I just thought this could be done, but in view of your explanation I
am now wiser ...

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




Wed, 19 Jan 2000 00:28:10 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] TODO list