From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
Cc: | Oleg Bartunov <obartunov(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PATCH] Generic type subscripting |
Date: | 2017-11-16 21:37:40 |
Message-ID: | CA+q6zcUn+9OnuMh3Mvu=XaNpSmLGo2HrYcowgJqCDrhKifaz+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 16 November 2017 at 12:40, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
wrote:
>
> Actually it is not only way to return isnull information.
What i've meant is that it's the only way if we want to keep the function
signature. Actually I would prefer this
(container, internal) -> extracted value
over this (I assume that's exactly what you've suggested?)
(container, internal, internal) -> extracted value
because it makes the purpose of the function more clear (especially for
custom
data types). Also it would be consistent with `assign` functions (since
`isnull` is not assigned there). But I see your point, a separate argument
for
`isnull` will make it more straightforward in terms of null handling.
> fetch() functions also doesn't need in ExprEvalStep struct
I had hard time parsing this, but from your examples I assume you're talking
about passing little bit different arguments to `fetch` function (am I
right?).
Just from functionality point of view I don't see a big difference in what
argument to use to return `isnull` by reference. So at the end I think we
need
to choose between having one or two `internal` arguments for `fetch`
functions.
Any other opinions?
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-11-16 21:40:50 | Re: bgwriter_lru_maxpages range in postgresql.conf |
Previous Message | Magnus Hagander | 2017-11-16 21:37:21 | Re: Schedule for migration to pglister |