Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id CA+q6zcUn+9OnuMh3Mvu=XaNpSmLGo2HrYcowgJqCDrhKifaz+A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-hackers
Tree view
> On 16 November 2017 at 12:40, Arthur Zakirov <a.zakirov@postgrespro.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?

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Schedule for migration to pglister
Next
From: Jeff Janes
Date:
Subject: Re: bgwriter_lru_maxpages range in postgresql.conf