Hello,
I've been stuck in mud trying to plperl work on windows
environment. I saw many messages complaining that plperl wouldn't
be built to work. For the convenience of those and myself, I
describe the process of building postgresql with plperl on
Windows with cygwin and VC++ I've done
On 06.07.2012 00:54, Jan Urbański wrote:
On 05/07/12 23:30, Peter Eisentraut wrote:
On tor, 2012-07-05 at 22:53 +0200, Jan Urbański wrote:
The problem is that PLyUnicode_Bytes is (via an ifdef) used as
PyString_ToString on Python3, which means that there are numerous call
sites and new ones
On 06/07/12 10:05, Heikki Linnakangas wrote:
On 06.07.2012 00:54, Jan Urbański wrote:
On 05/07/12 23:30, Peter Eisentraut wrote:
On tor, 2012-07-05 at 22:53 +0200, Jan Urbański wrote:
The problem is that PLyUnicode_Bytes is (via an ifdef) used as
PyString_ToString on Python3, which means that
On 07/06/2012 02:13 AM, Bruce Momjian wrote:
On Thu, Jul 05, 2012 at 10:10:08PM +0200, Antonin Houska wrote:
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of new year's day changes needs to be
updated, if such exists.
What version of Postgres is this?
Hi all,
On Thu, Jun 28, 2012 at 5:16 AM, David E. Wheeler da...@justatheory.com
wrote:
I don't see the virtue of this in this case. Since the index is not
unique, why not just put the index on (a,b,c,d) and be done with it?
Is there some advantage to be had in inventing a way to store c
Yes, it's a bug and it needs to be applied !
On Tue, Jul 3, 2012 at 7:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 3, 2012 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 21, 2012 at 2:53 PM, Alexander Korotkov
On Mon, Jul 2, 2012 at 8:51 PM, Greg Smith g...@2ndquadrant.com wrote:
snip
The INSTR implementation in the docs will instead search backwards from the
end of the string if you tell it to start at 0, same as if you gave it a
negative input. I think it's therefore possible to get the plpgsql
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not DumpableObject.
I suggest adding char *funcsig to FuncInfo, and moving the funcsig =
Tom Lane t...@sss.pgh.pa.us writes:
This argument seems a bit irrelevant to me. pg_dump doesn't get to pick
and choose what will be in the database it's told to dump. If we're
Sure.
going to do something like what Joel wants, we have to have file naming
conventions for operator and cast
On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
This argument seems a bit irrelevant to me. pg_dump doesn't get to pick
and choose what will be in the database it's told to dump. If we're
Sure.
going to do something like
On Fri, Jun 29, 2012 at 08:10:03AM +0200, Csaba Nagy wrote:
Hi all,
On Thu, Jun 28, 2012 at 5:16 AM, David E. Wheeler da...@justatheory.com
wrote:
I don't see the virtue of this in this case. Since the index is not
unique, why not just put the index on (a,b,c,d) and be done with it?
Hello,
Is it imaginable to additionally generate an index file that map the
half friendly file names to a cleartext object signature ?
This would allow user to possibly postprocess the output while merging
overloaded functions to single files or renaming the files according to
their needs and
Le vendredi 6 juillet 2012 15:41:01, Bruce Momjian a écrit :
On Fri, Jun 29, 2012 at 08:10:03AM +0200, Csaba Nagy wrote:
Hi all,
On Thu, Jun 28, 2012 at 5:16 AM, David E. Wheeler
da...@justatheory.com wrote: I don't see the virtue of this in this
case. Since the index is not
On 24 June 2012 04:01, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jun 23 18:08:31 -0400 2012:
I spotted a couple of other issues during testing:
David, when you generate a new version of the patch, please also make
sure to use
Csaba Nagy ncsli...@googlemail.com writes:
Why not restrict it to UNIQUE indexes ?
What benefit would such a restriction provide? AFAICS it doesn't make
implementation any easier.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 06/07/12 10:14, Jan Urbański wrote:
On 06/07/12 10:05, Heikki Linnakangas wrote:
In the backend elog routines, there is a global variable
'recursion_depth', which is incremented when an error-handling routine
is entered, and decremented afterwards. Can we use a similar mechinism
in
On 06.07.2012 18:01, Jan Urbański wrote:
There's still trouble with EUC_TW and MULE_INTERNAL which don't have
Python equivalents. EUC-TW has been discussed in
http://bugs.python.org/issue2066 and rejected (see
http://bugs.python.org/issue2066#msg113731).
If you use any of these encodings, you
On Fri, Jul 06, 2012 at 11:06:28AM +0200, Antonin Houska wrote:
On 07/06/2012 02:13 AM, Bruce Momjian wrote:
On Thu, Jul 05, 2012 at 10:10:08PM +0200, Antonin Houska wrote:
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of new year's day changes needs
On Wed, Apr 18, 2012 at 10:29:26AM -0400, Robert Haas wrote:
IME, bug trackers typically work best when used by a tightly
integrated team.
Well, very many loosely distributed open-source projects use bug
trackers quite successfully.
So I think Greg has exactly the right idea: we
Robert Haas robertmh...@gmail.com writes:
Here is an incremental documentation patch which I hope you will like.
Definitely, it's better this way. I'm not thrilled with separating it
into its own top level chapter, but I can see how it makes sense indeed.
This part is strange though:
+ A
On Fri, Jul 6, 2012 at 12:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 6, 2012 at 7:21 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Robert Haas robertmh...@gmail.com writes:
Attached is a incremental patch with a bunch of minor cleanups,
including reverts of a few
Robert Haas robertmh...@gmail.com writes:
And here is another incremental patch, this one doing some more
cleanup. Some of this is cosmetic, but it also:
Thanks, applied in my github repository!
I'm feeling pretty good about this at this point, although I think
there is still some more work
Hello
I updated my two years old patch
http://archives.postgresql.org/pgsql-hackers/2010-07/txtIakTCBA15Z.txt
Syntax is based on Florian Pflog's proposal
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00110.php
postgres=# do (a int, b int, text) $$begin raise notice '% % %', $1,
$2,
On Fri, Jul 6, 2012 at 3:29 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Here is an incremental documentation patch which I hope you will like.
Definitely, it's better this way. I'm not thrilled with separating it
into its own top level chapter, but I can see how it makes sense indeed.
On Fri, Jul 6, 2012 at 4:00 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
And here is another incremental patch, this one doing some more
cleanup. Some of this is cosmetic, but it also:
Thanks, applied in my github repository!
Thanks.
I have
On fre, 2012-07-06 at 18:53 +0300, Heikki Linnakangas wrote:
What shall we do about those? Ignore them? Document that if you're sing
one of these encodings then PL/Python with Python 2 will be crippled and
with Python 3 just won't work?
We could convert to UTF-8, and use the PostgreSQL
On tor, 2012-07-05 at 23:52 +0200, Dimitri Fontaine wrote:
I would argue like Álvaro that when dealing with operators and casts
you're probably writing an extension already, and we're providing
another way to deal with that.
I have code in the wild that defines new operators and casts and has
Excerpts from Alex's message of jue abr 19 17:06:05 -0300 2012:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2012-04-19 at 00:13 +0300, Alex wrote:
+#!/usr/bin/env perl
Don't do that. Call the script using $(PERL) from the makefile.
Thank you for the suggestion. Attached v2
On fre, 2012-06-15 at 00:01 +0300, Heikki Linnakangas wrote:
1. Use a 64-bit segment number, instead of the log/seg combination. And
don't waste the last segment on each logical 4 GB log file. The concept
of a logical log file is now completely gone. XLogRecPtr is unchanged,
but it should
On 06/07/12 22:47, Peter Eisentraut wrote:
On fre, 2012-07-06 at 18:53 +0300, Heikki Linnakangas wrote:
What shall we do about those? Ignore them? Document that if you're sing
one of these encodings then PL/Python with Python 2 will be crippled and
with Python 3 just won't work?
We could
On Thu, Jun 14, 2012 at 10:01 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This has the advantage that you can calculate the CRC for all the other
fields before acquiring WALInsertLock. For xl_prev, you need to know where
exactly the record is inserted, so it's handy that
I haven't had the time to finish all the issues with this, but I want to
keep the discussion going in the meantime and provide an updated patch.
On mån, 2012-06-18 at 17:33 +0200, Andres Freund wrote:
Cursory code review:
* pstrndup already exists as pnstrdup (hstore_plperl.c)
Fixed.
*
On tis, 2012-07-03 at 14:52 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On tis, 2012-07-03 at 19:35 +0200, Andres Freund wrote:
I wonder if we just should add a format code like %R or something similar
as a
replacement for the %X/%X notion.
Maybe just print it as
On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian br...@momjian.us wrote:
I think our big gap is in integrating these sections. There is no easy
way for a bug reporter to find out what happens to his report unless the
patch is applied in the same email thread as the report. It is hard for
users
On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote:
On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian br...@momjian.us wrote:
I think our big gap is in integrating these sections. There is no easy
way for a bug reporter to find out what happens to his report unless the
patch is
Attached is a revision of this patch, with a few clean-ups, mostly to
the wording of certain things.
On 5 July 2012 17:41, Pavel Stehule pavel.steh...@gmail.com wrote:
* renamed auxiliary functions and moved it elog.c - header is new file
relerror.h
In my revision, I've just added a
I wonder if maybe the nearest step towards better bug tracker is a more
readily referenceable mail archive.
Clearly, one of our frictions is searching for relevant messages, so
improved mail archive == lowered friction, no?
There's a very particular use case; people keep rueing that indexes get
On Fri, Jul 06, 2012 at 08:44:13PM -0400, Christopher Browne wrote:
I wonder if maybe the nearest step towards better bug tracker is a more
readily referenceable mail archive.
Clearly, one of our frictions is searching for relevant messages, so
improved
mail archive == lowered friction,
On Fri, Jul 6, 2012 at 6:41 PM, Daniel Farina dan...@heroku.com wrote:
I do basically agree with this. I was reflecting on the bug tracker
issue (or lack thereof) for unrelated reasons earlier today and I
think there are some very nice things to recommend the current
email-based system, which
Today I learnt [1,2,3] that the feature ALTER TABLE .. ADD CONSTRAINT ...
USING INDEX we added back in the day is not so useful in the field. Having
to drop foreign key constraints before this command, and recreate them
afterwards makes this command useless to most database setups. I feel sorry
40 matches
Mail list logo
