| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump vs. TRANSFORMs |
| Date: | 2016-05-11 05:16:11 |
| Message-ID: | 04738f95-2dd4-0d8e-397a-e65720cab36f@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 5/5/16 8:33 AM, Stephen Frost wrote:
> I strongly disagree with the idea that this is only an issue with the
> testing system. What if we add functions in the future that are
> created by initdb and *are* useful for transforms? What about casts?
> There are a lot of functions in pg_catalog that a user might wish to use
> to define their own cast. This also doesn't do anything about users
> creating functions in pg_catalog.
+1 to all of that. I know that I've at least created casts using
built-in functions during testing, and I think I might be doing it in
some of my extensions.
As for transforms, I suspect we're going to end up with some of those in
initdb in the future, because it's currently the only way you can
improve existing type transformations without breaking existing PL code.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2016-05-11 05:36:48 | Re: what to revert |
| Previous Message | Jim Nasby | 2016-05-11 05:07:18 | Re: Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump) |