On Sat, 24 Nov 2007 17:22:35 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain wrote:
Log Message:
---
Add regression tests for MONEY type.
This has broken the buildfarm ...
It worked here. Can you send me the error output.
--
D'Arcy J.M. Cain [EMAIL PROTECTED]
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 Sat, 2007-11-24 at 17:06 -0500, Greg Smith wrote:
On Sat, 24 Nov 2007, Tom Lane wrote:
[PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs
Applied.
Getting positive feedback that your archive command has triggered is
helpful for new users of this feature, and
On Nov 25, 2007 8:06 AM, Tom Lane [EMAIL PROTECTED] wrote:
The TPS numbers bounce around by 1% or so on repeated trials, so I
wouldn't put too much faith in small differences. What it looks like
to me is that it's all about the stats collection overhead. The drop on
01-17 corresponds to
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 Nov 24, 2007 5:50 PM, Gregory Stark [EMAIL PROTECTED] wrote:
It would be nice to have infrastructure similar to the buldfarm running a
standard set of benchmarks every day. It would be fascinating to see the
graphs day-by-day of performance. Hopefully we wouldn't see too many dips and
just
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 tryed implement quote_literal function with anyelement parametr. It
works for all specified types, but I have problem with unknown type.
Is it cstring? I can understand prohibition in SQL or PLPGSQL, but why
I cannot use it in C language.
Regards
Pavel Stehule
Guillaume Smet [EMAIL PROTECTED] writes:
Using pgbench -n -S -c 10 -t 10, I also have CVS tip as fast as
CVS from january. But using my set of queries, it's not.
Were you ever able to send your queries?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about
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
Guillaume Smet [EMAIL PROTECTED] writes:
Using pgbench -n -S -c 10 -t 10, I also have CVS tip as fast as
CVS from january. But using my set of queries, it's not.
Would you show us the test case you're using?
regards, tom lane
---(end of
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] wrote:
This has broken the buildfarm ...
It worked here. Can you send me the error output.
The problem was you forgot to update serial_schedule.
regards, tom lane
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 Nov 25, 2007 6:41 PM, Tom Lane [EMAIL PROTECTED] wrote:
Would you show us the test case you're using?
Sure, it's the same queries I posted earlier. My pgbench script is the
following:
BEGIN
select libvil from vilsitelang where codelang='FRA' and codevil='LYO'
select TL.motsclesmetatags,
Guillaume Smet [EMAIL PROTECTED] writes:
On Nov 25, 2007 6:41 PM, Tom Lane [EMAIL PROTECTED] wrote:
Would you show us the test case you're using?
Sure, it's the same queries I posted earlier.
What about the table schemas?
I send a link to the data to both of you in private.
I doubt that
On Nov 25, 2007 7:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
What about the table schemas?
The schema is in the dump. That's the main reason why I've sent the
dump to both of you.
Anyway, here it is:
db=# \d themelang
Table public.themelang
Column | Type
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 Nov 26, 2007 3:58 AM, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On Mon, Nov 26, 2007 at 03:51:37AM +1100, Brendan Jurd wrote:
I noticed in the 8.3 release notes that ARRAY(SELECT ...) now returns
an empty array if there are no rows returned by the subquery.
This has come up before,
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,
Guillaume Smet [EMAIL PROTECTED] writes:
Sure, it's the same queries I posted earlier. My pgbench script is the
following:
BEGIN
select libvil from vilsitelang where codelang='FRA' and codevil='LYO'
select TL.motsclesmetatags, TL.descriptifmeta, TL.motcleoverture_l,
TL.motcleoverture_c,
On Nov 26, 2007 1:35 AM, Tom Lane [EMAIL PROTECTED] wrote:
The cost of resolving ambiguous operators has been an issue for a long
time, of course, but it seems particularly bad in this case --- gprof
blames 37% of the runtime on oper_select_candidate(). It might be time
to think about caching
On Nov 26, 2007 1:54 AM, Guillaume Smet [EMAIL PROTECTED] wrote:
From what you say, I understand we can't even find a workaround for
8.3 to improve the situation while waiting for a cleaner solution in
8.4+?
To explain the reasons why I'm so worried, I should have explained
that all the
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:
But since your columns are varchar, which doesn't have any operators of its
own, we have to go through oper_select_candidate()
I wonder whether at some point we shouldn't just eliminate this distinction
entirely. Just make text and varchar the same type and
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
But since your columns are varchar, which doesn't have any operators of its
own, we have to go through oper_select_candidate()
I wonder whether at some point we shouldn't just eliminate this distinction
entirely. Just
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
28 matches
Mail list logo
