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
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
> en
"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
"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 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 pr
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 ca
"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.motcleovertu
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 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
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
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
"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 dou
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, TL
"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
"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
--
"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
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
"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
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
--
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 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
>
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 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 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
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
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 P
28 matches
Mail list logo