| From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
|---|---|
| To: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DOMAINs and CASTs |
| Date: | 2011-05-17 05:11:14 |
| Message-ID: | 4DD20372.6020908@darrenduncan.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jaime Casanova wrote:
> On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> we should probably try to agree on which
>> of the various options you mention makes most sense.
>
> well... my original patch only handle the simplest case, namely, try
> to make the cast that the user wants and if none is defined fall to
> the base types...
>
> anything else will complicate things as you shown... actually, things
> looks very simple until we start creating trees of domains...
> what options look sane to you?
The sanest option I see is don't overload the CAST syntax for subtypes. Just
call the foo2bar() function instead. You still get code with the same level of
terseness and that is just as easy to read and understand, and there is no
question of semantics. Also, that solution works right now. -- Darren Duncan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc-André Laverdière | 2011-05-17 12:41:14 | Support for cert auth in JDBC |
| Previous Message | Jaime Casanova | 2011-05-17 04:29:21 | Re: DOMAINs and CASTs |