Обсуждение: proposal: generic function, constructor function
Hello
I propose two kinds of functions:
a) generic functions - this function allows any params without any
implicit casting (it can implemented only in C language). This
function have to have specified return type. It usable for constructor
function and for some other. It allows unspecified number of params
without parser changes. There are not limits for params (only max
number) and there are not any implicit casting. Any parameter can take
additional tag with AS keyword.
Limits: only one function with specified name can exists in schema.
Sample:
CREATE FUNCTION format(any)
RETURNS text LANGUAGE C ....;
SELECT format(1, 'aaa' AS b, ARRAY[1,2,3]) -> '(1, b:"aaa",[1,2,3])'
generic function can be well used for constructor function
b) constructor function - this function returns typed composite or
array value. It's in conformance with ANSI SQL. Constructor function
is any generic function where name is same like any composite type or
domain. Behave of constructor is same for all types.
Sample:
CREATE TYPE ftype AS (a integer, b integer);
SELECT ftype(), ftype(10), ftype(10,20); -> (NULL, NULL), (10,NULL), (10,20) ~ (10,20)::ftype
CREATE DOMAIN fdom AS int[];
SELECT fdom(), fdom(10,20,30); -> '{}','{10,20,30}'; ~ it's eq ARRAY[10,20,30]::int[];
Why constructors?
Composite values are referenced in SQL/PSM. When I wont to fill
composite variables directly, I have to call constructor before:
DECLARE v mytype;
SET v = mytype();
SET v.f = 10; ~ or shortly SET v = mytype(10);
Any comments are welcome
Regards
Pavel Stehule
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> I propose two kinds of functions:
> a) generic functions - this function allows any params without any
> implicit casting (it can implemented only in C language).
Can't you do that already with ANYELEMENT, or at the worst ANY?
> It allows unspecified number of params
> without parser changes.
Why is that a good idea (and if you think it won't take parser changes,
you're wrong)?
> Limits: only one function with specified name can exists in schema.
This is why it's a bad idea. Please note that the unique index on
pg_proc cannot enforce that, even if we wanted such a restriction.
regards, tom lane
On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Pavel Stehule" <pavel.stehule@gmail.com> writes: > > I propose two kinds of functions: > > > a) generic functions - this function allows any params without any > > implicit casting (it can implemented only in C language). > > Can't you do that already with ANYELEMENT, or at the worst ANY? Anyelement is related with casting to common type. postgres=# create or replace function fx(anyelement, anyelement) returns text as $$begin return 'ahoj'; end; $$ language plpgsql; CREATE FUNCTION postgres=# select fx(1,'a'); ERROR: invalid input syntax for integer: "a" postgres=# select fx(1,'a'); I would to have independent parameters and move type checking to function. Then I don't need register function exactly and then I can have different numbers of arguments. It's similar like C varargs functions so now I cannot effectively implement printf function, because all parameters are casted to varchar. Using any is broken. ? postgres=# create or replace function fx1(any) returns text as $$begin return 'ahoj'; end; $$ language plpgsql; ERROR: syntax error at or near "any" LINE 1: create or replace function fx1(any) returns text as $$begin ... ^ > > > It allows unspecified number of params > > without parser changes. > > Why is that a good idea (and if you think it won't take parser changes, > you're wrong)? Of course. Implementation needs some changes in parser. But new generic function doesn't need it. With generic functions some xml functions could exists outside parser. And it's simple tool for constructors. > > > Limits: only one function with specified name can exists in schema. > > This is why it's a bad idea. Please note that the unique index on > pg_proc cannot enforce that, even if we wanted such a restriction. > we can use partial unique index, if it is possible - I didn't test it. Regards Pavel Stehule > regards, tom lane >
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Can't you do that already with ANYELEMENT, or at the worst ANY?
> I would to have independent parameters and move type checking to
> function.
Okay, then you want ANY.
> Then I don't need register function exactly and then I can
> have different numbers of arguments.
The different-numbers-of-arguments bit is what I'm objecting to.
Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
etc, and you're done without breaking anything else.
> we can use partial unique index, if it is possible - I didn't test it.
It's not --- partial indexes on system catalogs are not supported, and
pg_proc is certainly one catalog that that restriction will never be
relaxed for. (How you going to execute a predicate without doing
function lookups?) I don't believe that the constraint could be
expressed as a partial index predicate anyway --- how will you say
that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
don't?
regards, tom lane
On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Pavel Stehule" <pavel.stehule@gmail.com> writes: > > On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Can't you do that already with ANYELEMENT, or at the worst ANY? > > > I would to have independent parameters and move type checking to > > function. > > Okay, then you want ANY. > > > Then I don't need register function exactly and then I can > > have different numbers of arguments. > > The different-numbers-of-arguments bit is what I'm objecting to. > Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY), > etc, and you're done without breaking anything else. It's what I unlike - but maybe. But I am not able create function with ANY params. Is it possible do it via CREATE FUNCTION .. ? > > > we can use partial unique index, if it is possible - I didn't test it. > > It's not --- partial indexes on system catalogs are not supported, and > pg_proc is certainly one catalog that that restriction will never be > relaxed for. (How you going to execute a predicate without doing > function lookups?) I don't believe that the constraint could be > expressed as a partial index predicate anyway --- how will you say > that foo(...) and foo(int) conflict, but foo(int) and foo(int,int) > don't? > no, I spoke about constraint - there can be only one function foo(anyparams) or any current functions. So lookup find nearest function or find generic function. Current implementation ensure unique params for overloaded functions without unique index too - so I thing Its possible. It's same mechanism. regards Pavel Stehule > regards, tom lane >
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> But I am not able create function with
> ANY params. Is it possible do it via CREATE FUNCTION .. ?
It's a reserved word :-(. Try "any"
regards, tom lane
On 19/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Pavel Stehule" <pavel.stehule@gmail.com> writes: > > But I am not able create function with > > ANY params. Is it possible do it via CREATE FUNCTION .. ? > > It's a reserved word :-(. Try "any" > > regards, tom lane > I did it postgres=# create or replace function fx1(any, any) returns text language C strict; ERROR: syntax error at or near "any" LINE 1: create or replace function fx1(any, any) returns text langua... ^ postgres=# do you have any sample, please, thank you Pavel
On Sat, 19 Jan 2008, Pavel Stehule wrote:
> On 19/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>>> But I am not able create function with
>>> ANY params. Is it possible do it via CREATE FUNCTION .. ?
>>
>> It's a reserved word :-(. Try "any"
>>
>> regards, tom lane
>>
>
> I did it
> postgres=# create or replace function fx1(any, any) returns text
> language C strict;
> ERROR: syntax error at or near "any"
> LINE 1: create or replace function fx1(any, any) returns text langua...
> ^
> postgres=#
>
> do you have any sample, please,
Tom said, try "any". Don't forget about double quotes
>
> thank you
> Pavel
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
> > do you have any sample, please, > > Tom said, try "any". Don't forget about double quotes > I am blind thank you Pavel
Hello
>
> The different-numbers-of-arguments bit is what I'm objecting to.
> Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
> etc, and you're done without breaking anything else.
>
I found simple solution, it uses ANY, but number of necessary ANY
arguments is generated dynamically:
FuncCandidateList
FuncnameGetCandidates(List *names, int nargs)
{ FuncCandidateList resultList = NULL; char *schemaname;.... /* anyparams has unlimeted
pronargs,we cannot check it */
if (pronargs == 1 && procform->proargtypes.values[0]
== ANYPARAMSOID) generic_function = true;
/* Ignore if it doesn't match requested argument count */ else if (nargs >= 0 && pronargs
!=nargs) continue;
.... /* * Okay to add it to result list */
if (!generic_function) { newResult = (FuncCandidateList)
palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid) + pronargs * sizeof(Oid));
newResult->pathpos = pathpos; newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs= pronargs; memcpy(newResult->args, procform->proargtypes.values,
pronargs * sizeof(Oid));
newResult->next = resultList; resultList = newResult; }
else { /* generic function hasn't own params, but we
know numbers and * we can use ANY type. */ int
i;
newResult = (FuncCandidateList) palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid) + nargs * sizeof(Oid));
newResult->pathpos = pathpos; newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs= nargs; for (i = 0; i < nargs; i++)
newResult->args[i]= ANYOID;
newResult->next = resultList; resultList = newResult; }
It is more simpler than I though and it works. With this technique I
don't need some mentioned restriction.
ANYPARAMS is only syntactic sugar for n x ANY
What do you thing about it, please?
Regards
Pavel Stehule
> > we can use partial unique index, if it is possible - I didn't test it.
>
> It's not --- partial indexes on system catalogs are not supported, and
> pg_proc is certainly one catalog that that restriction will never be
> relaxed for. (How you going to execute a predicate without doing
> function lookups?) I don't believe that the constraint could be
> expressed as a partial index predicate anyway --- how will you say
> that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
> don't?
>
> regards, tom lane
>