
Can I ask how our big open items for 7.0 are doing:

	Long tuples/TOAST(Jan)
	Foriegn keys/action buffer(Jan)
	Unify date/time types(Thomas)
	Outer Joins(Thomas)

I am only asking to know if we should continue with the planned Feb 1
beta?

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

Tue, 18 Jan 2000 22:41:40 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Status on 7.0
Bruce Momjian wrote:
> 
> Can I ask how our big open items for 7.0 are doing:
> 
>         Long tuples/TOAST(Jan)
>         Foriegn keys/action buffer(Jan)
>         Unify date/time types(Thomas)
>         Outer Joins(Thomas)

Will we also have a possibility to ALTER constraints (NULL, CHECK, FOREIGN
KEY)

AFAIK, we can currently only change UNIQUE (by dropping the UNIQUE index),

--------------
Hannu

Wed, 19 Jan 2000 10:11:28 +0200
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] Status on 7.0
> Can I ask how our big open items for 7.0 are doing:
>         Unify date/time types(Thomas)

Will do this after getting the outer join syntax going...

>         Outer Joins(Thomas)

I've finally gotten back to work on this in the last couple of days.
Remember, at the moment I've only committed to getting *syntax*, but
that we were hoping to push this into the planner/optimizer/executor
soon after.

> I am only asking to know if we should continue with the planned Feb 1
> beta?

I'll be able to do the date/time unification once my parser is back
together and stable (no point in doing it earlier because I'll need a
stable parser to follow up on problem reports). Not sure about making
Feb 1, though I'll guess that the date/time unification is a couple of
days work once I start.

Remember that I'll need two weeks or so to package the docs before
final release, so will need some padding at the end of beta without
too much distraction from other problem reports :(

                    - Thomas

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

Wed, 19 Jan 2000 15:27:41 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Status on 7.0
> Can I ask how our big open items for 7.0 are doing:

istm that pg_dump could benefit greatly if it translated internal
Postgres type names to the SQL92-standard names. For example, int4 ->
integer, int8 -> bigint, etc. This would be analogous to the
translation we do when parsing queries in the backend, converting
(e.g.) integer -> int4.

This feature would make it a bit easier to move databases around, esp.
away from Postgres for those who have to...

Anyone interested in looking at this? If not, can you add it to the
ToDo Bruce?

                     - Thomas

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

Wed, 19 Jan 2000 15:40:11 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Status on 7.0
On 2000-01-18, Bruce Momjian mentioned:

> 
> Can I ask how our big open items for 7.0 are doing:
> 
> 	Long tuples/TOAST(Jan)
> 	Foriegn keys/action buffer(Jan)
> 	Unify date/time types(Thomas)
> 	Outer Joins(Thomas)
> 
> I am only asking to know if we should continue with the planned Feb 1
> beta?

Are we going to yank DISTINCT ON?

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



Thu, 20 Jan 2000 18:55:04 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Status on 7.0
On 2000-01-19, Thomas Lockhart mentioned:

> istm that pg_dump could benefit greatly if it translated internal
> Postgres type names to the SQL92-standard names. For example, int4 ->
> integer, int8 -> bigint, etc. This would be analogous to the
> translation we do when parsing queries in the backend, converting
> (e.g.) integer -> int4.

I certainly think this is a good idea, but I don't consider the proposed
approach too good. The reason is that the next thing you'd have to do is
fix up psql as well, creating one more source of inconsistency. Not to
mention other similar applications which we don't have any control over,
such as pgbash.

What I'd suggest -- and the 7.0 release is certainly one of the better
times to do this -- is to change the catalog entries to "integer",
"bigint", etc. and instead do the translation of the "deprecated" (or
"traditional", if you like) types "int4", "int8", etc. into the standard
ones. As far as I can see this would require only two changes for each
datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
transparently to the rest of the code. And client applications don't need
to know this at all.

Is there a problem with this I'm not seeing (other than perhaps affective
attachment to Postgres'isms)? This almost seems too trivial to not have
been done already.


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




Thu, 20 Jan 2000 18:55:28 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Re: Status on 7.0
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 2000-01-18, Bruce Momjian mentioned:
> 
> > 
> > Can I ask how our big open items for 7.0 are doing:
> > 
> > 	Long tuples/TOAST(Jan)
> > 	Foriegn keys/action buffer(Jan)
> > 	Unify date/time types(Thomas)
> > 	Outer Joins(Thomas)
> > 
> > I am only asking to know if we should continue with the planned Feb 1
> > beta?
> 
> Are we going to yank DISTINCT ON?

I don't show DISTINCT ON as being worked on by anyone.

-- 
  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, 20 Jan 2000 13:11:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Status on 7.0
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 2000-01-19, Thomas Lockhart mentioned:
> 
> > istm that pg_dump could benefit greatly if it translated internal
> > Postgres type names to the SQL92-standard names. For example, int4 ->
> > integer, int8 -> bigint, etc. This would be analogous to the
> > translation we do when parsing queries in the backend, converting
> > (e.g.) integer -> int4.
> 
> I certainly think this is a good idea, but I don't consider the proposed
> approach too good. The reason is that the next thing you'd have to do is
> fix up psql as well, creating one more source of inconsistency. Not to
> mention other similar applications which we don't have any control over,
> such as pgbash.
> 
> What I'd suggest -- and the 7.0 release is certainly one of the better
> times to do this -- is to change the catalog entries to "integer",
> "bigint", etc. and instead do the translation of the "deprecated" (or
> "traditional", if you like) types "int4", "int8", etc. into the standard
> ones. As far as I can see this would require only two changes for each
> datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
> transparently to the rest of the code. And client applications don't need
> to know this at all.
> 
> Is there a problem with this I'm not seeing (other than perhaps affective
> attachment to Postgres'isms)? This almost seems too trivial to not have
> been done already.

[The big incomatibility alarm goes off.]

We have to discuss if this is a good idea.  I am not sure.

-- 
  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, 20 Jan 2000 13:12:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: Status on 7.0
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Are we going to yank DISTINCT ON?
>
> I don't show DISTINCT ON as being worked on by anyone.

I proposed removing it, but hadn't gotten around to doing anything
about it.  Partly, I've been waiting to see if anyone would complain
that it should stay...

			regards, tom lane

Thu, 20 Jan 2000 17:54:20 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Status on 7.0 
> What I'd suggest -- and the 7.0 release is certainly one of the better
> times to do this -- is to change the catalog entries to "integer",
> "bigint", etc. and instead do the translation of the "deprecated" (or
> "traditional", if you like) types "int4", "int8", etc. into the standard
> ones. As far as I can see this would require only two changes for each
> datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
> transparently to the rest of the code. And client applications don't need
> to know this at all.
> Is there a problem with this I'm not seeing (other than perhaps affective
> attachment to Postgres'isms)? This almost seems too trivial to not have
> been done already.

One reason this hasn't been done is that we would lose the
(occasional) correspondence between internal names and external names,
which isn't a very good reason.

I've also thought that we might implement some "by reference" types to
replace the "by value" types we have now (and use the SQL92 names for
them). But Tom Lane has talked about fixing up the internal problems
we have with passing info about NULLs with "by value" types, so that
might be a bad way to head. However, the downside to eliminating "by
value"s (extra footprint?) might be offset by being able to remove
code which has to handle both cases (extra speed?).

                     - Thomas

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

Fri, 21 Jan 2000 03:36:32 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Status on 7.0
> One reason this hasn't been done is that we would lose the
> (occasional) correspondence between internal names and external names,
> which isn't a very good reason.
> 
> I've also thought that we might implement some "by reference" types to
> replace the "by value" types we have now (and use the SQL92 names for
> them). But Tom Lane has talked about fixing up the internal problems
> we have with passing info about NULLs with "by value" types, so that
> might be a bad way to head. However, the downside to eliminating "by
> value"s (extra footprint?) might be offset by being able to remove
> code which has to handle both cases (extra speed?).

I have added a TODO item:

	* add pg_dump option to dump type names as standard ANSI types

-- 
  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, 20 Jan 2000 22:52:13 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: Status on 7.0
Bruce Momjian wrote:

> Can I ask how our big open items for 7.0 are doing:
>
>         Long tuples/TOAST(Jan)
>         Foriegn keys/action buffer(Jan)
>         Unify date/time types(Thomas)
>         Outer Joins(Thomas)
>
> I am only asking to know if we should continue with the planned Feb 1
> beta?

     I know now that I have to do all the missing FOREIGN KEY stuff
     myself. And thats not the file buffering alone. We cannot ship
     FOREIGN KEY if pg_dump cannot handle it.

     Up to now, nothing I did for TOAST changed anything visible. So it
     has to wait for FK.

     Currently, I'm a little busy, so I don't expect TOAST for 7.0
     anymore - sorry.



Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #




Fri, 21 Jan 2000 09:39:03 +0100
Jan Wieck <wieck@debis.com>
Re: Status on 7.0
>      I know now that I have to do all the missing FOREIGN KEY stuff
>      myself. And thats not the file buffering alone. We cannot ship
>      FOREIGN KEY if pg_dump cannot handle it.
> 
>      Up to now, nothing I did for TOAST changed anything visible. So it
>      has to wait for FK.
> 
>      Currently, I'm a little busy, so I don't expect TOAST for 7.0
>      anymore - sorry.

That's fine.  Better to say it now and take the pressure of yourself.

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

Fri, 21 Jan 2000 10:11:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Status on 7.0
On 2000-01-20, Bruce Momjian mentioned:

> > Are we going to yank DISTINCT ON?
> 
> I don't show DISTINCT ON as being worked on by anyone.

I think Tom mentioned several times that he would like to yank it because
a) it's non-standard
b) it's conceptually flawed
c) there's a standard alternative
d) it doesn't work too well
e) people keep trying to use it

Just making sure no one forgets ...

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



Sat, 22 Jan 2000 15:24:36 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Status on 7.0
On 2000-01-21, Thomas Lockhart mentioned:

> > What I'd suggest -- and the 7.0 release is certainly one of the better
> > times to do this -- is to change the catalog entries to "integer",
> > "bigint", etc. and instead do the translation of the "deprecated" (or
> > "traditional", if you like) types "int4", "int8", etc. into the standard
> > ones.

> I've also thought that we might implement some "by reference" types to
> replace the "by value" types we have now (and use the SQL92 names for
> them). But Tom Lane has talked about fixing up the internal problems
> we have with passing info about NULLs with "by value" types, so that
> might be a bad way to head. However, the downside to eliminating "by
> value"s (extra footprint?) might be offset by being able to remove
> code which has to handle both cases (extra speed?).

Well, rather than creating a huge potential hazard for everyone two weeks
before beta I'm going to settle for a cheaper solution (for now). There
are just too many subtleties that one would have to address early in a
devel cycle, so I'll put that on the the Forget-me-not list for 7.1.

Instead I'd suggest extending the idea of gram.y's xlateSqlType to two
functions provided by the backend

type_sql_to_internal
type_internal_to_sql

which psql and pg_dump could use. Once we switch some or all datatypes
over, this would be the only place we'd need to change -- until it's an
empty function at the end.

Comments? Better ideas?

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



Sun, 23 Jan 2000 02:30:43 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Re: Status on 7.0
> Well, rather than creating a huge potential hazard for everyone two weeks
> before beta I'm going to settle for a cheaper solution (for now). There
> are just too many subtleties that one would have to address early in a
> devel cycle, so I'll put that on the the Forget-me-not list for 7.1.

Right.

> Instead I'd suggest extending the idea of gram.y's xlateSqlType to two
> functions provided by the backend
> type_sql_to_internal
> type_internal_to_sql
> which psql and pg_dump could use. Once we switch some or all datatypes
> over, this would be the only place we'd need to change -- until it's an
> empty function at the end.

Sounds good to me. Unless we embed this knowledge in a table
somewhere, which perhaps we should have done originally. But then we
would have lots of overhead on queries...

                    - Thomas

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

Mon, 24 Jan 2000 15:58:09 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Status on 7.0
Already added to TODO list.


> > Can I ask how our big open items for 7.0 are doing:
> 
> istm that pg_dump could benefit greatly if it translated internal
> Postgres type names to the SQL92-standard names. For example, int4 ->
> integer, int8 -> bigint, etc. This would be analogous to the
> translation we do when parsing queries in the backend, converting
> (e.g.) integer -> int4.
> 
> This feature would make it a bit easier to move databases around, esp.
> away from Postgres for those who have to...
> 
> Anyone interested in looking at this? If not, can you add it to the
> ToDo Bruce?
> 
>                      - Thomas
> 
> -- 
> Thomas Lockhart				lockhart@alumni.caltech.edu
> South Pasadena, California
> 


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

Fri, 2 Jun 2000 12:01:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Status on 7.0
Bruce Momjian writes:

> > istm that pg_dump could benefit greatly if it translated internal
> > Postgres type names to the SQL92-standard names. For example, int4 ->
> > integer, int8 -> bigint, etc. This would be analogous to the
> > translation we do when parsing queries in the backend, converting
> > (e.g.) integer -> int4.

I once proposed to create a function `format_type' or some such which
would take an internal type name and a modifier and format it to some
canonical representation. I recall that was well received and I'm still
interested in that, but I'd let the function manager changes die down
first.


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


Sun, 4 Jun 2000 00:44:46 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: Status on 7.0