Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers
| From | Arthur Zakirov |
|---|---|
| Subject | Re: [HACKERS] [PATCH] Generic type subscripting |
| Date | |
| Msg-id | 20171031150515.GA20467@zakirov.localdomain Whole thread Raw |
| In response to | Re: [HACKERS] [PATCH] Generic type subscripting (Dmitry Dolgov <9erthalion6@gmail.com>) |
| Responses |
Re: [HACKERS] [PATCH] Generic type subscripting
|
| List | pgsql-hackers |
On Sun, Oct 29, 2017 at 10:56:19PM +0100, Dmitry Dolgov wrote:
>
> So, here is the new version of patch that contains modifications we've
> discussed, namely:
>
> * store oids of `parse`, `fetch` and `assign` functions
>
> * introduce dependencies from a data type
>
> * as a side effect of previous two I also eliminated some unnecessary
> arguments
> in `parse` function.
Thank you for new version of the patch.
There are some notes.
Documentation
-------------
Documentation is compiled. But there are warnings about end-tags. Now it is necessary to have full named end-tags:
=# make -C doc/src/sgml check
/usr/sbin/onsgmls:json.sgml:574:20:W: empty end-tag
...
Documentation is out of date:
- catalogs.sgml needs to add information about additional pg_type fields
- create_type.sgml needs information about subscripting_parse, subscripting_assign and subscripting_fetch options
- xsubscripting.sgml is out of date
Code
----
I think it is necessary to check Oids of subscripting_parse, subscripting_assign, subscripting_fetch. Maybe within
TypeCreate().
Otherwise next cases possible:
=# CREATE TYPE custom ( internallength = 8, input = custom_in, output = custom_out, subscripting_parse =
custom_subscripting_parse);
=# CREATE TYPE custom ( internallength = 8, input = custom_in, output = custom_out, subscripting_fetch =
custom_subscripting_fetch);
Are all subscripting_* fields mandatory? If so if user provided at least one of them then all fields should be
provided.
Should all types have support assigning via subscript? If not then subscripting_assign parameter is optional.
> +Datum
> +jsonb_subscript_parse(PG_FUNCTION_ARGS)
> +{
> + bool isAssignment = PG_GETARG_BOOL(0);
and
> +Datum
> +custom_subscripting_parse(PG_FUNCTION_ARGS)
> +{
> + bool isAssignment = PG_GETARG_BOOL(0);
Here isAssignment is unused variable, so it could be removed.
> +
> + scratch->d.sbsref.eval_finfo = eval_finfo;
> + scratch->d.sbsref.nested_finfo = nested_finfo;
> +
As I mentioned earlier we need assigning eval_finfo and nested_finfo only for EEOP_SBSREF_OLD, EEOP_SBSREF_ASSIGN and
EEOP_SBSREF_FETCHsteps.
Also they should be assigned before calling ExprEvalPushStep(), not after. Otherwise some bugs may appear in future.
> - ArrayRef *aref = makeNode(ArrayRef);
> + NodeTag sbstag = nodeTag(src_expr);
> + Size nodeSize = sizeof(SubscriptingRef);
> + SubscriptingRef *sbsref = (SubscriptingRef *) newNode(nodeSize, sbstag);
Is there necessity to use newNode() instead using makeNode(). The previous code was shorter.
There is no changes in execnodes.h except removed line. So I think execnodes.h could be removed from the patch.
>
> I'm going to make few more improvements, but in the meantime I hope we can
> continue to review the patch.
I will wait.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: