Tom Lane wrote:
I don't offhand see anything else I'd consider weakening the casting
rules for. If anyone else is interested, I took
...
substring(text,integer) |
substring(text,integer,integer) |
substring(text,text)
On Sat, 24 Nov 2007 21:17:39 -0500 Tom Lane wrote:
Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes:
we have some plpgsql functions which use quote_literal() regardless of
the data type. With Beta 3 this does not work anymore[1].
If you're unwilling to fix your application, you can hack
On Nov 25, 2007 11:51 PM, Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote:
But that's not the point: more people will run into this problem and
this looks like a showstopper for updating to 8.3.
By the way, the function is named quote_literal(), not quote_text().
From my point of view i
Hello
Having quote_literal take its argument as text was fine whilst we were
automatically casting arguments, but in 8.3 it seems that
quote_literal(anyelement) makes a lot more sense than
quote_literal(text).
So, I wonder why we don't just adapt the internal function to take
anyelement?
Hello
I sent patch to pg_patches.
Regards
Pavel Stehule
---(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
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
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
On Nov 26, 2007 5:23 AM, 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
On Mon, 26 Nov 2007 06:35:20 +1100 Brendan Jurd wrote:
On Nov 26, 2007 5:23 AM, Tom Lane [EMAIL PROTECTED] 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,
Brendan Jurd [EMAIL PROTECTED] writes:
On Nov 26, 2007 5:23 AM, Tom Lane [EMAIL PROTECTED] wrote:
... 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.
I took your
Tom Lane [EMAIL PROTECTED] writes:
Thoughts?
I wouldn't have thought set_config was frequently enough used to warrant a
catalog change but quote_literal does seem like a common enough use case to
warrant it and once we're doing it there...
I started to think md5(bytea) would be reasonable but
Tom Lane wrote:
[...]
it seems that quote_literal() has a good case,
and you could also make an argument for allowing a non-text second
argument for set_config()
[...]
Thoughts?
I think there is just enough of a case for quote_literal(), although in
my experience the
Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes:
we have some plpgsql functions which use quote_literal() regardless of
the data type. With Beta 3 this does not work anymore[1].
If you're unwilling to fix your application, you can hack around that
for yourself.
regression=# select
13 matches
Mail list logo
