| 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: | Whole Thread | Raw Message | 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 |