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)
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 va
"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
"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
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, uni
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 p
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 th
"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 induci
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 t
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
> anyel
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
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
"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 quote_
Hello all,
testing 8.3b3, i found out an interesting thing:
we have some plpgsql functions which use quote_literal() regardless of
the data type. With Beta 3 this does not work anymore[1].
Given the fact, that some functions do a lot of work, you (or at least
we) don't want to look, if the data
14 matches
Mail list logo
