Re: quote_literal(integer) does not exist

From: Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: quote_literal(integer) does not exist
Date: 2007-11-25 22:35:46
Message-ID: 20071125233546.44929433@iridium.wars-nicht.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 26 Nov 2007 06:35:20 +1100 Brendan Jurd wrote:

> On Nov 26, 2007 5:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I'm all for the idea of making people conscious of text coercions in
> general, but in the *particular* case of quote_literal, having it only
> accept text is undesirable, unintuitive and most importantly, it will
> break apps which otherwise may have been able to enjoy a smooth
> transition to 8.3.
>
> I would argue that quote_literal should have been set up to accept
> anyelement in the very first place, and I'd guess that the original
> choice of text as an argument type was partially driven by the
> understanding that everything gets coerced to text, making it a de
> facto "anyelement" substitute. Or maybe anyelement wasn't available
> when it was introduced. Either way, if quote_literal() is all about
> safely stuffing variables into dynamic queries, the new behaviour is a
> regression. In context, it makes perfect sense to throw integers,
> numerics and whatever else at quote_literal and expect it to Just
> Work.

The problem for me is: we expect and encourage people to do safe
programming and now they have to debug their programs and remove
some of the "safe" parts just to make PostgreSQL happy.
As you said, that is not, what the average programmer expect.

> My feeling is that the change in text coercion behaviour has well
> illuminated that the text argument type for quote_literal isn't ideal.
> Great! Let's fix it.

Yes, Tom Lane is right that the current behavior is broken. But the
solution cannot be to exclude anything beside text but instead we
should move forward to accept anything (at least, if it's possible).

> > 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.
>
> I'd pass on changing quote_ident. It seems natural for it to take a
> text argument. I can imagine a lot of people using, say,
> quote_literal(int) in the field; I can't imagine the same for
> quote_ident.

True. You can't even create a table who's name is just an integer or
where the name starts with an integer, so in any way you already have
to use quotes and you are aware of the problem.

> I can see your reluctance to force an initdb, but what's the greater
> mischief; forcing initdb in beta, or breaking applications on release?
> My personal perspective is that it's an easy choice ... avoid
> breaking the apps, that's what betas are for.

Yeah, that's what a beta is for. We don't expect to have people running
production systems with beta software so it needs an reinstall anyway
after the release.

Kind regards

--
Andreas 'ads' Scherbaum
PostgreSQL User Group Germany

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-11-26 00:35:23 Re: 8.3devel slower than 8.2 under read-only load
Previous Message Brendan Jurd 2007-11-25 20:08:24 Re: [GENERAL] Empty arrays with ARRAY[]