pá 29. 7. 2022 v 18:35 odesílatel napsal:
> On 2022-07-28 01:51, Pavel Stehule wrote:
> >> Would it be clearer to say:
> >>
> >> It also contains the OID of the intended procedural language and
> >> whether
> >> that procedural language is declared as TRUSTED.
> >> While these values are redundan
On 2022-07-28 01:51, Pavel Stehule wrote:
Would it be clearer to say:
It also contains the OID of the intended procedural language and
whether
that procedural language is declared as TRUSTED.
While these values are redundant if the inline handler is serving only
a single procedural language, t
čt 28. 7. 2022 v 4:06 odesílatel napsal:
> On 2022-07-13 00:26, Pavel Stehule wrote:
>
> > 1. I am not sure if get_call_trftypes is a good name - the prefix
> > get_call
> > is used when some runtime data is processed.
>
> I guess I hadn't caught on that the prefix carried that meaning.
> To me,
On 2022-07-13 00:26, Pavel Stehule wrote:
1. I am not sure if get_call_trftypes is a good name - the prefix
get_call
is used when some runtime data is processed.
I guess I hadn't caught on that the prefix carried that meaning.
To me, it appeared to be a prefix used to avoid being specific to
Hi
I am doing an review of this patch and I have two comments
1. I am not sure if get_call_trftypes is a good name - the prefix get_call
is used when some runtime data is processed. This function just returns
reformatted data from the system catalogue. Maybe get_func_trftypes_list,
or just replac
On 2022-02-22 12:59, Chapman Flack wrote:
It would have been painful to write documentation of get_func_trftypes
saying its result isn't what get_transform_{from.to}sql expect, so
patch 1 does add a get_call_trftypes that returns a List *.
Patch 2 then updates the docs as discussed in this threa
On 02/21/22 16:09, Chapman Flack wrote:
> On 02/07/22 15:14, Chapman Flack wrote:
>> I'll work on some doc patches.
>
> It seems a bit of an impedance mismatch that there is a get_func_trftypes
> producing a C Oid[] (with its length returned separately), while
> get_transform_fromsql and get_trans
On 02/07/22 15:14, Chapman Flack wrote:
> I'll work on some doc patches.
It seems a bit of an impedance mismatch that there is a get_func_trftypes
producing a C Oid[] (with its length returned separately), while
get_transform_fromsql and get_transform_tosql both expect a List.
There is only one i
On 02/07/22 15:14, Chapman Flack wrote:
> It has since occurred to me that another benefit of having a
> transform_validator per PL would be immediate error reporting
> if someone, for whatever reason, tries out CREATE TRANSFORM
> for a PL that doesn't grok transforms.
The same could be achieved,
On 02/07/22 10:59, Peter Eisentraut wrote:
> On 05.02.22 00:55, Chapman Flack wrote:
>> I'm thinking plhandler.sgml is the only place that really needs to be
>> ...
>> worth mentioning there, though, that it isn't possible to develop
>> transforms for an arbitrary PL unless that PL applies transfor
On 05.02.22 00:55, Chapman Flack wrote:
I'm thinking plhandler.sgml is the only place that really needs to be
said; readers looking up CREATE TRANSFORM and using an existing PL that
supports it don't need to know how the sausage is made. (Maybe it is
worth mentioning there, though, that it isn't
Hi,
It looks to me as if the transforms feature for PLs was added in
cac7658, and support was added to plperl and plpython at that time,
with documentation added for CREATE FUNCTION, CREATE/DROP TRANSFORM,
and the catalogs, but nothing was added at that time to plhandler.sgml
to clarify that a PL
12 matches
Mail list logo
