On Fri, Jan 1, 2010 at 12:21 PM, Tom Lane wrote:
>
>> another parameter that is interesting is seq_page_cost, AFAIUI all the
>> other cost parameters (in the planner section of course) are relative
>> to this one. so what is the logic in allow changing it?
>
> Please read the discussions that went
Greg Stark writes:
> On Sun, Jan 3, 2010 at 1:21 AM, Tom Lane wrote:
>> If the conditions
>> were phrased in a way that made them indexable, they might be worth the
>> trouble --- but they aren't.
> Wow, that is weird, especially since it's *easier* to write them
> properly using LIKE anyways.
2010/1/3 Andrew Dunstan :
>
>
> Hitoshi Harada wrote:
>>
>> A question: Isn't there no possibility that we have our own
>> implementation to handle JSON (i.e. no use of external libraries)?
>>
>>
>>
>
> Why should we reinvent a wheel someone else has already invented? This is
> what shared librarie
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This
is what shared libraries are all about.
cheers
andrew
--
Sent v
2010/1/3 Peter Eisentraut :
> On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
>> Mine for one :-). Quite apart from any other reason I would expect it to
>> make indexing parts of the JSON more tractable. Say we use it to store a
>> web session object, which is a natural enough use. I migh
Peter Eisentraut wrote:
On fre, 2010-01-01 at 16:32 +0100, Magnus Hagander wrote:
I therefor propose that we rename this file to "config.pl.default",
and change the scripts to first load config.pl.default, and then load
config.pl if it exists.
I'd keep the naming so that the extensio
2010/1/2 Peter Eisentraut :
> On tor, 2009-12-31 at 11:28 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > The definition of c.h is bogus anyway. You might think it contains
>> > includes and defines to set up a portable C environment, which is what
>> > the first half indeed does.
>>
>> >
On Sun, Jan 3, 2010 at 1:21 AM, Tom Lane wrote:
> If the conditions
> were phrased in a way that made them indexable, they might be worth the
> trouble --- but they aren't.
Wow, that is weird, especially since it's *easier* to write them
properly using LIKE anyways.
--
greg
--
Sent via pgsql
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the encoding
error and issue a customised error message, but this plugs all the holes
I can see with the possible exceptio
This evening's argument about DO completion caused me to look a bit
closer at tab-complete.c than I ever had before. I am now wondering
exactly why we bother with all the logic like
" WHERE substring(pg_catalog.quote_ident(rolname),1,%d)='%s'"
in the SQL queries that it issues. It appears to m
On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
> Mine for one :-). Quite apart from any other reason I would expect it to
> make indexing parts of the JSON more tractable. Say we use it to store a
> web session object, which is a natural enough use. I might well want to
> find or modif
Peter Eisentraut writes:
> On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
>> As for the overhead, these queries are not zero-maintenance. I still
>> think that the usefulness of tab completion here is pretty darn
>> minimal,
>> since most people are more likely to rely on default_do_language
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
> As for the overhead, these queries are not zero-maintenance. I still
> think that the usefulness of tab completion here is pretty darn
> minimal,
> since most people are more likely to rely on default_do_language;
We really don't have any data
On sön, 2010-01-03 at 00:24 +0100, Magnus Hagander wrote:
> On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut wrote:
> > On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
> >> On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut wrote:
> >> > On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrot
Bruce Momjian writes:
> OK, so my question is whether __int64 is the right definition or only
> what Python chose.
I see no reason to question either the width or the signedness.
If you do, feel free to research away.
regards, tom lane
--
Sent via pgsql-hackers mailing
Magnus Hagander wrote:
> On Sun, Jan 3, 2010 at 01:01, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Tom Lane wrote:
> >> >> I think the Python guys are up against the same problem as us, namely
> >> >> substituting for the platform's failure to define the type.
> >>
On Sun, Jan 3, 2010 at 01:01, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Tom Lane wrote:
>> >> I think the Python guys are up against the same problem as us, namely
>> >> substituting for the platform's failure to define the type.
>>
>> > I am unclear if accepting what P
Bruce Momjian writes:
> Well, I saw two definitions listed in this thread, and it wasn't clear
> to me the Python one was known to be the correct one:
> PostgreSQL has it as
> typedef long ssize_t;
That one is our 32-bit-only definition.
regards, tom lane
--
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think the Python guys are up against the same problem as us, namely
> >> substituting for the platform's failure to define the type.
>
> > I am unclear if accepting what Python chose as a default is the right
> > route vs. doing m
Bruce Momjian writes:
> Tom Lane wrote:
>> I think the Python guys are up against the same problem as us, namely
>> substituting for the platform's failure to define the type.
> I am unclear if accepting what Python chose as a default is the right
> route vs. doing more research.
What exactly do
Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut wrote:
> >> Seems kind of buggy. ?They shouldn't be defining it at all.
>
> > Why not? Should they just stop using it? In that case, so should we, no?
>
> What's buggy is M$ failing to provide it in the
Magnus Hagander writes:
> On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut wrote:
>> Seems kind of buggy. They shouldn't be defining it at all.
> Why not? Should they just stop using it? In that case, so should we, no?
What's buggy is M$ failing to provide it in their header.
It's unlikely they
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut wrote:
> On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
>> On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut wrote:
>> > On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
>> >> When trying to build plpython on win64, it fails because
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
> On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut wrote:
> > On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
> >> When trying to build plpython on win64, it fails because ssize_t is
> >> defined differently.
> >>
> >> PostgreSQL ha
Hannu Krosing wrote:
[plperl can return data that is not valid in the server encoding and it
is not caught]
This results in a table, which has invalid utf sequence in it and
consequently does not pass dump/load
What would be the best place to fix this ?
Should there be checks in all text
David Fetter writes:
>> My inclination is to not have the separate query at all,
> I made one so people couldn't tab complete themselves an unpleasant
> surprise. The overhead doesn't seem huge.
What unpleasant surprise is that going to be? They'll get an error
message telling them there's no
It is possible to get an invalid byte sequence into a text field via pl,
in this case pl/perl :
---8<--8<--8<--8<--8<--8<---
CREATE TABLE utf_test
(
id serial PRIMARY KEY,
data character varying
);
CREATE OR REPLACE FUNCTION invalid_utf_seq()
RETURNS character varying A
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote:
> David Fetter writes:
> >> It doesn't actually work, because the query isn't paying attention to
> >> the current partial word. Try do language pl, or just compare
> >> source to the original Query_for_list_of_languages.
>
> > Thanks for
David Fetter writes:
>> It doesn't actually work, because the query isn't paying attention to
>> the current partial word. Try do language pl, or just compare
>> source to the original Query_for_list_of_languages.
> Thanks for the heads-up. New patch attached :)
My inclination is to not have t
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
> >> (b) wrong in detail.
>
> > How?
>
> It doesn't actually work, because the query isn't paying attention to
> the current partial word. Try do langua
David Fetter writes:
> On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
>> (b) wrong in detail.
> How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl, or just compare
source to the original Query_for_list_of_languages.
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Please find enclosed a patch which adds tab completion for DO
> > blocks.
>
> Seems (a) rather pointless and
I don't find it so.
> (b) wrong in detail.
How? That it can't look back past the code block is refl
David Fetter writes:
> Please find enclosed a patch which adds tab completion for DO blocks.
Seems (a) rather pointless and (b) wrong in detail.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Folks,
Please find enclosed a patch which adds tab completion for DO blocks.
Thanks to Andrew Gierth and Stefan Kaltenbrunner for help putting it
together :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP:
On Sat, Jan 2, 2010 at 16:59, Tom Lane wrote:
> Magnus Hagander writes:
>> I'm not entirely sure what the type is for, though,
>
> It's supposed to be the same width as size_t but signed. I would assume
> that it should be 64 bits on Win64.
Yeah, seems reasonable. I'll put in that #ifdef in win
Mark Cave-Ayland writes:
> Please find the revised v2 patch attached for comment. The one thing I
> have done is separated out the moduledir variable into datamoduledir and
> docmoduledir so there is a little bit of wiggle room if someone needs to
> install DATA items and DOCS items in differen
KaiGai Kohei writes:
> (2009/12/30 10:38), Robert Haas wrote:
>> No longer applies. Can you rebase?
> The attached patch is the rebased revision.
I'm not really impressed with this patch, because it will reject
perfectly legitimate multiple-inheritance cases (ie, cases where there's
more than o
2010/1/2 Tom Lane :
> Pavel Stehule writes:
>> here is patch
>
> I looked at this patch a bit, and I think the real problem with it is
> that it's not multibyte safe. You've copied backend code that is
> allowed to assume it's in a safe encoding (ie, one where multibyte
> characters can't contain
2010/1/2 Tom Lane :
> Pavel Stehule writes:
>> a) print correct message and exit(1)
>
> Which part of "no, you're not doing that" wasn't clear to you?
>
> The error handling in this function should be no different from that
> in the existing escaping functions. exit(1) is completely unacceptable
Pavel Stehule writes:
> here is patch
I looked at this patch a bit, and I think the real problem with it is
that it's not multibyte safe. You've copied backend code that is
allowed to assume it's in a safe encoding (ie, one where multibyte
characters can't contain non-high-bit-set bytes). This
Pavel Stehule writes:
> a) print correct message and exit(1)
Which part of "no, you're not doing that" wasn't clear to you?
The error handling in this function should be no different from that
in the existing escaping functions. exit(1) is completely unacceptable.
regar
2009/12/30 Robert Haas :
> On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> here is patch
>
> The error handling in quote_literal() doesn't look right to me. The
> documentation for PQescapeStringConn says that it stores an error
> message in the conn object, but your code ignores that
Magnus Hagander wrote:
> On Sat, Jan 2, 2010 at 03:13, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> I have adapted the win64 patches a bit, and now have a working build.
> >> As in it runs the regression tests fine. However, I have well over a
> >> thousand warnings of the type:
> >> conve
Magnus Hagander writes:
> I'm not entirely sure what the type is for, though,
It's supposed to be the same width as size_t but signed. I would assume
that it should be 64 bits on Win64.
According to SUS this type should be provided by sys/types.h:
http://www.opengroup.org/onlinepubs/007908799/x
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut wrote:
> On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
>> When trying to build plpython on win64, it fails because ssize_t is
>> defined differently.
>>
>> PostgreSQL has it as
>> typedef long ssize_t;
>>
>> And python has it as:
>> typede
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
> When trying to build plpython on win64, it fails because ssize_t is
> defined differently.
>
> PostgreSQL has it as
> typedef long ssize_t;
>
> And python has it as:
> typedef __int64 ssize_t;
What file/line is that? I don't see that i
(2009/12/30 10:38), Robert Haas wrote:
2009/12/16 KaiGai Kohei:
It is a patch for the matter which I reported before.
When a column is inherited from multiple relations, ALTER TABLE with
RENAME TO option is problematic.
This patch fixes the matter. In correctly, it prevent to rename columns
inh
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef __int64 ssize_t;
The postgresql deifnition comes from include/port/win32.h, which leads
me to think that we should just change that on
On fre, 2010-01-01 at 16:32 +0100, Magnus Hagander wrote:
> I therefor propose that we rename this file to "config.pl.default",
> and change the scripts to first load config.pl.default, and then load
> config.pl if it exists.
I'd keep the naming so that the extension .pl is preserved. Helps
edito
Tom Lane wrote:
If you can set it up in such a way that the default behavior doesn't
change, this would be workable. I don't think we want people to
suddenly find their stuff installing in the wrong place.
It probably wouldn't be that hard, something along the lines of
ifndef MODULEDIR
Sergej Galkin writes:
> I realized my own gist index, and now I want to debug it :)
I used Gevel for that:
http://www.sai.msu.su/~megera/wiki/Gevel
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Hello all,
With New Year !
I realized my own gist index, and now I want to debug it :) I want to use
amdb program
http://gist.cs.berkeley.edu/libgist-2.0/install.html
But I have problem with installing it.
When I running "gmake cmdline"
It doesn't find iostream.h file :( and uses g++ (it is c++ c
On Sat, Jan 2, 2010 at 02:20, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> I therefor propose that we rename this file to "config.pl.default",
>> and change the scripts to first load config.pl.default, and then load
>> config.pl if it exists. config.pl then lives completely outside the
>> s
On Sat, Jan 2, 2010 at 03:13, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> I have adapted the win64 patches a bit, and now have a working build.
>> As in it runs the regression tests fine. However, I have well over a
>> thousand warnings of the type:
>> conversion from 'size_t' to 'int', possi
Hi,
Simon Riggs wrote:
> In practice, many lock contention situations are caused by long running
> idle transactions, so having a deadlock detector be able to resolve a
> situation by deciding that an idle xact is actually in some kind of wait
> state would be very useful.
Hm.. so you'd abort the
55 matches
Mail list logo
