On 04/19/25 19:32, Chapman Flack wrote:
> On 04/19/25 19:12, Tom Lane wrote:
>> You could argue that
>> CREATE FUNCTION foo(anyelement) RETURNS anyelement
>> TRANSFORM FOR TYPE int
>> AS ...;
>> should mean that if the actual argument type is int, then the
>> mentioned transform should be applied t
probably precomputed and cached
a good deal of information, including what transforms are requested and
what parameter positions are polymorphic if any, and only needs to check
those when specializing, and funccache can preserve those results too.
Regards,
-Chap
hould be applied to the input and result;
but if it's some other type then just do the normal conversions.
You could perhaps also argue that that's a bad idea. I'm not sure.
It does make for very dynamic matching of transforms to arguments,
which feels dubious to me, but I can'
w if it falls foul of the wording of
> the spec, and I concede that in some cases it'd require users
> to do more work creating those additional transforms.
I don't see right offhand that it would fall afoul of the spec.
I had also proposed in that earlier CF to change some of w
BTW, there is another way in which the current rules for transform
application are not self-consistent. Postgres has three kinds of
container types: arrays, composites, and ranges. But the transform
code special-cases only arrays. I'd have thought that if the idea is
to specify transforms
he spec, and I concede that in some cases it'd require users
to do more work creating those additional transforms.
regards, tom lane
Also noticing about transforms:
1. protrftypes can have duplicates.
In part, this is because CreateFunction does nothing to stop you saying
redundant things like TRANSFORM FOR TYPE circle, FOR TYPE circle.
But it is also because:
2. CreateFunction hands every type seen in TRANSFORM
t these session
values apply at function-creation time to types for which the CREATE
FUNCTION specifies no transform explicitly, but it does say that default
transforms will be supplied for those, with the defaults being
implementation-defined. So defaulting to session-wide settings would
not be wrong
get_transform_tosql and
get_transform_fromsql when there isn't any TRANSFORM clause at all?"
> If pg_proc had protransforms instead, that would add a step zero: looking
> up the declared transforms to make an in-memory list of (typid, tosqloid,
> fromsqloid). After that, get_tra
the passed typid isn't found
in the passed list of trftypes.
If pg_proc had protransforms instead, that would add a step zero: looking
up the declared transforms to make an in-memory list of (typid, tosqloid,
fromsqloid). After that, get_transform_{tosql,fromsql} would be applied
and return quickl
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
duction of procedures, so
I have changed many instances of 'function' to the umbrella term
'routine'.
Patch 3 simply reindents for the new section markup and rewraps.
Whitespace only.
Patch 4 updates src/test/modules/plsample to demonstrate handling of
transforms (and to add some mo
s.
Whitespace only.
Patch 4 updates src/test/modules/plsample to demonstrate handling of
transforms (and to add some more comments generally).
I'll add this to the CF.
Regards,
-Chap
>From 7e6027cdcf1dbf7a10c0bad5059816cef762b1b9 Mon Sep 17 00:00:00 2001
From: Chapman Flack
only one in-core caller of get_func_trftypes (it is
print_function_trftypes in ruleutils.c), while both in-core PLs that
currently support transforms are reduced to rolling their own List by
grabbing the protrftypes Datum and hitting it with oid_array_to_list.
Would it be reasonable to d
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
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 a
t it isn't possible to develop
transforms for an arbitrary PL unless that PL applies transforms.)
makes sense
I noticed the CREATE TRANSFORM docs show the argument list as
(argument_type [, ...]) even though check_transform_function will reject
any argument list of length other than 1 or
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
On 2018-11-19 17:53:22 -0800, Andres Freund wrote:
> Hi Peter, Alvaro, All,
>
> (Peter, this is your change, Alvaro, you're the objectaddress.c master)
>
> While looking through my oids removal patch I noticed that the
> objectaddress.c ObjectProperty entry for
Hi Peter, Alvaro, All,
(Peter, this is your change, Alvaro, you're the objectaddress.c master)
While looking through my oids removal patch I noticed that the
objectaddress.c ObjectProperty entry for transforms looks wrong:
typedef struct
{
Oid clas
24 matches
Mail list logo
