Hello
2009/7/30 Robert Haas :
> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
>> Hello
>>
>> new patch add new contrib "transformations" with three modules
>> anotation, decode and json.
>>
>> These modules are ported from my older work.
>>
>> Before applying this patch, please use named-f
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my older work.
>
> Before applying this patch, please use named-fixed patch too. The hook
> doesn't need i
"Tao Ma" writes:
> I knew that the delete_function() will reclaim the memory context
> allocated for the function. But I did not find any code for removing
> the plan(SPI plan memory context), saved by calling _SPI_save_plan.
Hmmm ... good point, those probably won't get cleaned up. In an
enviro
Steve Prentice writes:
> On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
>> Tom added a comment in 1995
> For the record, I meant 2005.
I was intending to say something like "I've been around this project
a long time, but not THAT long" ...
regards, tom lane
--
Sent
Robert Haas writes:
> Hmm, well if I understand this correctly (now), it's similar to allowing:
> void
> test2(int a)
> {
> a = 2;
> return;
> }
> ...which is a fairly common programming practice that I don't think is
> particularly considered bad style, or at least certainly not by
> everyone.
On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
Tom added a comment in 1995
For the record, I meant 2005.
-Steve
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 29, 2009 at 9:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice wrote:
>>> Is there a reason we force plpgsql IN parameters to constant?
>
>> Wow. I can imagine about a thousand ways that this could break
>> existing applications. I would
On Wed, Jul 29, 2009 at 9:05 PM, Steve Prentice wrote:
> On Jul 29, 2009, at 5:26 PM, Robert Haas wrote:
>>
>> Wow. I can imagine about a thousand ways that this could break
>> existing applications. I would not be prepared to bet a dollar that
>> anything I've written would survive the impact un
Andrew Dunstan writes:
> First reaction is that it would mean we could never pass them by
> reference. I know PLPerl uses in effect pass by copy, but what does
> PLPgsql do?
It's not really an issue, because plpgsql keeps track of whether
the current value of the variable "belongs" to it or not
Robert Haas writes:
> On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice wrote:
>> Is there a reason we force plpgsql IN parameters to constant?
> Wow. I can imagine about a thousand ways that this could break
> existing applications. I would not be prepared to bet a dollar that
> anything I've wr
On Jul 29, 2009, at 5:23 PM, Andrew Dunstan wrote:
First reaction is that it would mean we could never pass them by
reference. I know PLPerl uses in effect pass by copy, but what does
PLPgsql do?
Isn't this effectively what we accomplish with an IN/OUT parameter?
--
Sent via pgsql-hackers
On Jul 29, 2009, at 5:26 PM, Robert Haas wrote:
Wow. I can imagine about a thousand ways that this could break
existing applications. I would not be prepared to bet a dollar that
anything I've written would survive the impact unscathed.
I have a feeling someone else is going to shoot you out o
On Wed, Jul 29, 2009 at 6:59 PM, Andres Freund wrote:
> Looks nice. The only small gripe I have is that the patch adds trailing
> whitespaces at a lot of places...
>
> Except maybe that I do see no need for changes anymore...
I have fixed this for Sergey in the attached version using "git apply
--
This patch is wrapping up nicely. I re-tested against the updated
pgbench-mt_20090724 and now I get similar results whether or not
--enable-thread-safety is enabled on Linux, so that problem is gone.
Josh's successful Windows tests along with finding the bug he attached a
patch to is also enco
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prentice wrote:
> Is there a reason we force plpgsql IN parameters to constant? The reason I
> ask is because having them mutable would go a long way in easing a port from
> Informix's SPL. For better or worse, we have a fair amount of code in SPL
> that does
Steve Prentice wrote:
Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:
-- pObjectId i
Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:
-- pObjectId is an IN parameter
I
Hi Sergey,
Sorry that the second round took almost as long as the first one...
On Monday 27 July 2009 12:01:46 Sergey V. Karpov wrote:
> > - Imho mode=MAP should error out if keeporig is false
> > - I personally find the the names for the different modes a bit
> > nondescriptive. One possibility
On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote:
> Huh, running the patched version on a single thread with 128 clients
> just got it to crash. Actually consistently, three times now. Will try
> the same thing on the development box tomorrow morning to get some
> better debugging informati
On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentraut wrote:
> On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
>> Included is a conceptual patch to use intptr_t. Comments are welcome.
>
> After closer inspection, not having a win64 box available, I have my doubts
> whether this patch actually doe
On Tue, Jul 21, 2009 at 3:55 PM, Dickson S. Guedes wrote:
>> I think there is enough support for the patch. So please adjust it to
>> report the server version correctly.
>
> Thanks Peter, I'll adjust the patch and post a new version ASAP.
As this patch was reviewed over a week ago and has not be
On Wed, Jul 29, 2009 at 5:00 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> [ deferrable unique constraints patch ]
>
> Applied after rather extensive editorialization. Aside from the points
Wow, cool.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Tom Lane wrote:
> Dean Rasheed writes:
> > [ deferrable unique constraints patch ]
>
> Applied after rather extensive editorialization.
Kudos!!
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hacke
Dean Rasheed writes:
> [ deferrable unique constraints patch ]
Applied after rather extensive editorialization. Aside from the points
we already discussed, I redid the logic in _bt_check_unique ... it
didn't look right to me, and I also felt that we need a cross-check
to verify that the original
pg...@mohawksoft.com wrote:
Well, the API is there, it is where, I guess, PostgreSQL is going, but I
think, philosophically, the API needs to see the XML contained within SQL
columns as being able to represent variable and optional columns in object
oriented environments easily. The harder it
Greg Stark writes:
> On Wed, Jul 29, 2009 at 5:15 PM, Tom Lane wrote:
>> I agree that we should change it, but should we back-patch it, and if so
>> how far?
> Well at least to 8.4 so someone who has just always been using
> downloaded binaries or binaries compiled with the default
> configuratio
> I put the old binary back and it works fine.
For the record, "fine" meaning I've never had the shared memory
problem.
Kev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Win2k3 Std SP2, the service won't start once I've applied the
patch. In the log, I get:
%t LOG: CreateProcess call failed: A blocking operation was
interrupted by a call to WSACancelBlockingCall.
(error code 2)
%t LOG: could not fork autovacuum worker process: A blocking
operation
>>
>> select datum form objects were key ='GUID' and
>> xpath_string(datum,E'foo/bar') = 'frobozz';
>>
>> The logic of the function seems is that it is intended to use extracted
>> XML within a query. The new xpath functionality seems not to be designed
>> to facilitate this, requiring a pretty ar
2009/7/18 Hitoshi Harada :
> If I understand exlain analyze correctly and it tells us the fact,
> WindowAgg without ORDER BY clause gets unreasonably slow. Let me see.
>
I haven't determined the difference between with and without ORDER BY
clause in OVER(), but I took a benchmark that throws an in
On Jul 28, 2009, at 6:15 AM, Peter Eisentraut wrote:
On Monday 27 July 2009 14:50:30 Alvaro Herrera wrote:
We've developed some code to implement fixed-length datatypes for
well
known digest function output (MD5, SHA1 and the various SHA2 types).
These types have minimal overhead and are quite
On Jul 23, 2009, at 6:22 AM, Laurent Laborde wrote:
On Wed, Jul 22, 2009 at 10:54 AM, Laurent
Laborde wrote:
My 1st applied patch is the safest and simpliest :
in pg_lzcompress.c :
static const PGLZ_Strategy strategy_default_data = {
256,/* Data chunks less than 256 are not compress
On Wed, Jul 29, 2009 at 5:15 PM, Tom Lane wrote:
> I agree that we should change it, but should we back-patch it, and if so
> how far?
>
Well at least to 8.4 so someone who has just always been using
downloaded binaries or binaries compiled with the default
configuration continues to get the same
Andrew Dunstan writes:
> And I still get these errors. Looks like at least SUSE is not keeping
> up. I'll build without the system timezones.
Or just live with it. The purpose of the regression tests is to let
you know there's a problem, not to dictate what you do about it.
In this case you nee
Brendan Jurd escreveu:
> Filling unused characters in the string with "#" may be strange, but
> changing it would require a much broader patch that covers all of the
> numeric formatting styles, not just . A TODO is probably the way
> to go.
>
That was my suggestion: a TODO.
> So if you put
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan writes:
Building 8.4 on a client's system, I get a regression failure
apparently due to some difference between the system's timezone DB
and what out regression tests expect, as shown below.
Those regression tests were *intenti
Gregory Stark writes:
> I think we broke date_part for extracting seconds from time arguments. It
> appears we leave out the milliseconds whereas we don't for timestamp
> arguments. This was not the case in 8.3 where we included the milliseconds for
> both data types.
It's not new. This appears
pg...@mohawksoft.com wrote:
On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote:
The thing that perplexed me was that it was not obvious from the docs
how,
exactly, to get the functionality that was simple and straight forward
in
XML2.
I continue to be in favor of adding
2009/7/29 Brendan Jurd :
> 2009/7/29 Euler Taveira de Oliveira :
>> This is not a problem with your patch but something that needs to be fixed in
>> PostgreSQL to match Oracle behavior. The following example should emit an
>> error. IMHO, filling the string with # is very strange. TODO?
>>
>> euler
2009/7/29 Euler Taveira de Oliveira :
> This is not a problem with your patch but something that needs to be fixed in
> PostgreSQL to match Oracle behavior. The following example should emit an
> error. IMHO, filling the string with # is very strange. TODO?
>
> euler=# SELECT to_char(1234.56789, '9
2009/7/28 Martijn van Oosterhout :
> On Tue, Jul 28, 2009 at 10:53:08PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> I would to solve some points from ToDo. I began with TYPE [] support.
>> I thing, so this should be relative simple, but there are one issue.
>
>
>
>> My first idea is using word elem
2009/7/29 Robert Haas :
> On Wed, Jul 29, 2009 at 1:44 AM, Pavel Stehule wrote:
>> 2009/7/29 Tom Lane :
>>> Pavel Stehule writes:
I would to solve some points from ToDo. I began with TYPE [] support.
>>>
>>> plpgsql's %type support is a crock that's going to have to be rewritten
>>> from the
I think we broke date_part for extracting seconds from time arguments. It
appears we leave out the milliseconds whereas we don't for timestamp
arguments. This was not the case in 8.3 where we included the milliseconds for
both data types.
Unless this is intentional? I know we wacked around both t
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Also, the followup to that message points out that the 8.4.0 code
>> has a potential O(N^2) dependency on the total number of TOC items
>> in the dump. So it might be interesting to check the behavior with
>> very large numbers of tables/indexes.
Le 29 juil. 09 à 13:07, Robert Haas a écrit :
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontaine> wrote:
I'm going to update the status of patch and resume work on it next
week.
Any update?
Sorry about delays, resuming tomorrow evening is the current plan.
--
dim
--
Sent via pgsql-hackers ma
> On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote:
>> The thing that perplexed me was that it was not obvious from the docs
>> how,
>> exactly, to get the functionality that was simple and straight forward
>> in
>> XML2.
>
> I continue to be in favor of adding
>
> xpath_string
> xpath_n
Tom Lane wrote:
> Also, the followup to that message points out that the 8.4.0 code
> has a potential O(N^2) dependency on the total number of TOC items
> in the dump. So it might be interesting to check the behavior with
> very large numbers of tables/indexes.
I've got 431 user tables with
Robert Haas wrote:
> This is what I've been able to find on a quick look:
>
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00678.php
>
> Sounds like Kevin may want to try renaming some of his indices to
> produce intermingling...
Thanks, I'll give that a try. Renaming them is on
On Wed, 29 Jul 2009, Peter Eisentraut wrote:
On Tuesday 14 July 2009 22:12:28 Oleg Bartunov wrote:
we'd like to introduce filtering dictionaries support for text search
and new contrib module unaccent, which provides useful example of
filtering dictionary. It finally solves the known problem of
Robert Haas writes:
> On Tue, Jul 28, 2009 at 9:52 PM, Tom Lane wrote:
>> I don't have time to look right now, but ISTM the original discussion
>> that led to making that patch had ideas about scenarios where it would
>> be faster.
> This is what I've been able to find on a quick look:
> http://a
Dean Rasheed writes:
> 2009/7/29 Tom Lane :
>> For non-unique indexes, it is not required that aminsert
>> do anything; it might for instance refuse to index NULLs.
> Doesn't this comment apply equally to unique indexes?
Hmm, I was thinking that a unique-capable index would have to index all
On Wed, Jul 29, 2009 at 8:43 AM, Peter Eisentraut wrote:
> On Sunday 28 June 2009 21:21:35 Robert Haas wrote:
>> I think that our dependencies for generated header files (gram.h,
>> fmgroids.h, probes.h) are not as good as they could be. What we do
>> right now is make src/backend/Makefile rebuild
On Sunday 28 June 2009 21:21:35 Robert Haas wrote:
> I think that our dependencies for generated header files (gram.h,
> fmgroids.h, probes.h) are not as good as they could be. What we do
> right now is make src/backend/Makefile rebuild these before recursing
> through its subdirectories. This wo
On Tuesday 14 July 2009 22:12:28 Oleg Bartunov wrote:
> we'd like to introduce filtering dictionaries support for text search
> and new contrib module unaccent, which provides useful example of
> filtering dictionary. It finally solves the known problem of
> incorrect generation of headlines of tex
Hi,
Thanks for the comment!
On Tue, Jul 28, 2009 at 12:27 AM, Tom Lane wrote:
> Well, actually, this description perfectly illustrates my basic
> complaint: the patch breaks the API abstraction provided by pqcomm.c.
> Callers are encouraged/forced to deal with the next layer down, and to
> the ex
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontaine wrote:
> I'm going to update the status of patch and resume work on it next week.
Any update?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Tue, Jul 28, 2009 at 9:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> The other possibility here is that this just doesn't work. :-)
>
> That's why we wanted to test it ;-).
>
> I don't have time to look right now, but ISTM the original discussion
> that led to making that patch had ideas abo
On Wed, Jul 29, 2009 at 1:44 AM, Pavel Stehule wrote:
> 2009/7/29 Tom Lane :
>> Pavel Stehule writes:
>>> I would to solve some points from ToDo. I began with TYPE [] support.
>>
>> plpgsql's %type support is a crock that's going to have to be rewritten
>> from the ground up as soon as we consolid
2009/7/29 Brendan Jurd :
> 2009/7/29 Euler Taveira de Oliveira :
>> Looks better but I did some tests and caught some strange behaviors.
>>
>
> Pavel,
>
> Any comment on these cases? When I looked at the patch I wasn't
> really sure why it filled the string with '#' either, but I didn't
> question
Hi,
I revised the patch according to the suggestion.
On Tue, Jul 28, 2009 at 4:08 PM, Fujii Masao wrote:
> On Tue, Jul 28, 2009 at 12:09 AM, Tom Lane wrote:
>> I think you're making things more complicated when they should be
>> getting simpler.
>>
>> It strikes me that the current API of "pass t
On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote:
> The thing that perplexed me was that it was not obvious from the docs how,
> exactly, to get the functionality that was simple and straight forward in
> XML2.
I continue to be in favor of adding
xpath_string
xpath_number
xpath_boolean
2009/7/29 Euler Taveira de Oliveira :
> Looks better but I did some tests and caught some strange behaviors.
>
Pavel,
Any comment on these cases? When I looked at the patch I wasn't
really sure why it filled the string with '#' either, but I didn't
question it.
Cheers,
BJ
--
Sent via pgsql-ha
2009/7/29 Tom Lane :
> Another thought on the index AM API issues: after poking through the
> code I realized that there is *nobody* paying any attention to the
> existing bool result of aminsert() (ie, did we insert anything or not).
> So I think that instead of adding a bool* parameter, we should
2009/7/28 Tom Lane :
> ... speaking of adding catalog columns, I just discovered that the patch
> adds searches of pg_depend and pg_constraint to BuildIndexInfo. This
> seems utterly unacceptable on two grounds:
>
> * It's sheer luck that it gets through bootstrap without crashing.
> Those aren't
64 matches
Mail list logo
