From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <jwieck(at)debis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: Status on 7.0 |
Date: | 2000-01-24 15:58:09 |
Message-ID: | 388C7691.C86A4AC3@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-24 16:06:55 | Re: [HACKERS] fatal copy in/out error (6.5.3) |
Previous Message | Adriaan Joubert | 2000-01-24 15:47:44 | Re: [HACKERS] Well, then you keep your darn columns |