Thread: Status on 7.0
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, Pennsylvania19026
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
> 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
> 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
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
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
[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, Pennsylvania19026
[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, Pennsylvania19026
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
> 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
> 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, Pennsylvania19026
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.
Wecannot 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) #
> 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, Pennsylvania19026
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
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
> 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
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, Pennsylvania19026
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