| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Mark Wong <markwkm(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc |
| Date: | 2013-07-08 01:28:34 |
| Message-ID: | 20130708012834.GA1151026@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jul 07, 2013 at 08:55:01PM -0400, Peter Eisentraut wrote:
> On Sun, 2013-07-07 at 20:15 -0400, Noah Misch wrote:
> > I mildly recommend we reject this patch as such, remove the TODO item,
> > remove
> > the XXX comments this patch removes, and plan not to add more trivial
> > SPI
> > wrappers. If consensus goes otherwise, I think we should at least
> > introduce
> > SPI_getcollation() at the same time. Code that needs to transfer one
> > of them
> > very often needs to transfer the other. Having API coverage for just
> > one
> > makes it easier for hackers to miss that.
>
> The question is, what would one do with those values? It's hard to see
> when you would need the typmod and the collation of a result set. There
> might be cases, but enough to provide a special API for it?
Good point. One of the ways PL/pgSQL uses it is to feed a result datum back
into a future query as a Param node.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2013-07-08 01:37:26 | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
| Previous Message | Peter Eisentraut | 2013-07-08 01:03:24 | Re: [PATCH] Add session_preload_libraries configuration parameter |