2009/7/28 Tom Lane t...@sss.pgh.pa.us:
... 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.
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
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*
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
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
--
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
Hi,
I revised the patch according to the suggestion.
On Tue, Jul 28, 2009 at 4:08 PM, Fujii Masaomasao.fu...@gmail.com wrote:
On Tue, Jul 28, 2009 at 12:09 AM, Tom Lanet...@sss.pgh.pa.us wrote:
I think you're making things more complicated when they should be
getting simpler.
It strikes me
2009/7/29 Brendan Jurd dire...@gmail.com:
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
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 '#'
On Wed, Jul 29, 2009 at 1:44 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
On Tue, Jul 28, 2009 at 9:52 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontainedfonta...@hi-media.com 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:
Hi,
Thanks for the comment!
On Tue, Jul 28, 2009 at 12:27 AM, Tom Lanet...@sss.pgh.pa.us 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,
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 text
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 works
On Wed, Jul 29, 2009 at 8:43 AM, Peter Eisentrautpete...@gmx.net 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
Dean Rasheed dean.a.rash...@googlemail.com writes:
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
For non-unique indexes, it is not required that functionaminsert/
do anything; it might for instance refuse to index NULLs.
Doesn't this comment apply equally to unique indexes?
Hmm, I was thinking
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 28, 2009 at 9:52 PM, Tom Lanet...@sss.pgh.pa.us 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
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
Robert Haas robertmh...@gmail.com 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.
Tom Lane t...@sss.pgh.pa.us 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
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
Le 29 juil. 09 à 13:07, Robert Haas a écrit :
On Sat, Jul 18, 2009 at 5:54 PM, Dimitri Fontainedfonta...@hi-media.com
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
--
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
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
2009/7/29 Robert Haas robertmh...@gmail.com:
On Wed, Jul 29, 2009 at 1:44 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I would to solve some points from ToDo. I began with TYPE [] support.
plpgsql's %type
2009/7/28 Martijn van Oosterhout klep...@svana.org:
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.
snip
My first idea is using
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
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
2009/7/29 Brendan Jurd dire...@gmail.com:
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
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
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
Gregory Stark st...@mit.edu 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.
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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 the
Andrew Dunstan and...@dunslane.net 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
On Wed, Jul 29, 2009 at 5:15 PM, Tom Lanet...@sss.pgh.pa.us 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
On Jul 23, 2009, at 6:22 AM, Laurent Laborde wrote:
On Wed, Jul 22, 2009 at 10:54 AM, Laurent
Labordekerdez...@gmail.com 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
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
2009/7/18 Hitoshi Harada umi.tan...@gmail.com:
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
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 arcane query
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
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
Greg Stark st...@mit.edu writes:
On Wed, Jul 29, 2009 at 5:15 PM, Tom Lanet...@sss.pgh.pa.us 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
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
Dean Rasheed dean.a.rash...@googlemail.com 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
Tom Lane wrote:
Dean Rasheed dean.a.rash...@googlemail.com writes:
[ deferrable unique constraints patch ]
Applied after rather extensive editorialization.
Kudos!!
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Wed, Jul 29, 2009 at 5:00 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@googlemail.com writes:
[ deferrable unique constraints patch ]
Applied after rather extensive editorialization. Aside from the points
Wow, cool.
...Robert
--
Sent via pgsql-hackers mailing list
On Tue, Jul 21, 2009 at 3:55 PM, Dickson S. Guedeslis...@guedesoft.net 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
On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentrautpete...@gmx.net 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
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 information.
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 would
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
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
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com 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
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
On Wed, Jul 29, 2009 at 6:59 PM, Andres Freundand...@anarazel.de 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
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
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com 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
Andrew Dunstan and...@dunslane.net 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
On Wed, Jul 29, 2009 at 9:05 PM, Steve Prenticeprent...@cisco.com 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
On Wed, Jul 29, 2009 at 9:08 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com wrote:
Is there a reason we force plpgsql IN parameters to constant?
Wow. I can imagine about a thousand ways that
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
Robert Haas robertmh...@gmail.com 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
Steve Prentice prent...@cisco.com 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
Tao Ma feng_e...@163.com 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.
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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
Hello
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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
64 matches
Mail list logo
