On 25/11/2007, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > So, I wonder why we don't just adapt the internal function to take
> > anyelement?
>
> The main argument against is the "slippery slope" one: once we accept
> this, what else? The entire point of that change was to make people
> be aware of where they are inducing text coercions, and deciding to
> hide that again on the basis of individual complaints is no way to
> design a system.
>
I know so is too late now. This patch can be saved for 8.4.
There is one reason for patching. It is consistence with || operator.
That's all. This patch doesn't change casting rules, and these rules
are strict still (what is good). But quote_literal is more natural
with anyelement parameter, than only text element. There isn't any
reason for some limit. This discus is not about change rules, but
about change of definition of some functions.
> As a not-too-far-away example, I see that the proposed patch Pavel
> sent in arbitrarily decides to change quote_ident() too, which was
> not asked for and has got much less justification than changing
> quote_literal(). That sort of cowboy approach to semantics is not
> the way to proceed.
>
Reason is same. Consistence with || operator. But, equivalent in SQL is:
CREATE OR REPLACE FUNCTION quote_ident(anyelement)
RETURNS text AS
SELECT CASE when $1::text LIKE '% %' <- first problem
THEN '"' || $1 || '"'
ELSE $1::text END <- second problem
$$ LANGUAGE SQL;
so, I see, with quote_ident I was wrong. I belive so with anyelement
can be more usable, but it is different than quote_literal.
> Another issue is that changing pg_proc.h without forcing initdb
> is not good practice. We are far enough along in the beta cycle
> that we shouldn't force initdb lightly, and I definitely *don't*
> want to do it again next week when someone else comes up with
> some other "must have" auto-coercing function. If anyone wants
> to make a serious argument for this, look through the whole of
> pg_proc.h, see what else needs to be changed at the same time,
> and make a coherent proposal.
>
probably quote_literal is more important than others. It is wide used
with dynamic selects. On other side, any similar problem can be simple
solved with custom wrapper (with some note in release notes).
I found more important problem. I cannot simply use literal in
polymorphic function. I cannot call anyfce('literal') what is
acceptable in SQL or plpgsql languages, but not in C language. Sure,
this topic is for 8.4.
nice a day
Pavel Stehule
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
