[ -> hackers ]

Tom Lane writes:

> > Will you expect the function to do dequoting etc. as well?  This might get
> > out of hand.
>
> Hm.  We already have such code available for nextval(),

IMHO, nextval() isn't the greatest interface in the world.  I do like the
alternative (deprecated?) syntax sequence.nextval() because of the
notational resemblence to OO.  (We might even be able to turn this into
something like an SQL99 "class" feature.)

As I understand it, currently

    relation.function(a, b, c)

ends up as being a function call

    function(relation, a, b, c)

where the first argument is "text".  This is probably an unnecessary
fragility, since the oid of the relation should already be known by that
time.  So perhaps we could change this that the first argument gets passed
in an Oid.  Then we'd really only need the Oid version of Joe's
has_*_privilege functions.

-- 
Peter Eisentraut   peter_e(at)gmx(dot)net   http://funkturm.homeip.net/~peter

In response to

• Re: Fw: Isn't pg_statistic a security hole - Solution Proposal at 2001-06-02 15:04:05 from Tom Lane

Responses

• Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal at 2001-06-03 17:17:21 from Tom Lane

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2001-06-03 17:17:21
	Subject: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:	From: Joe Conway	Date: 2001-06-03 03:22:44
	Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal

pgsql-patches by date

Next:	From: Tom Lane	Date: 2001-06-03 17:17:21
	Subject: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:	From: Joe Conway	Date: 2001-06-03 03:22:44
	Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal