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
tha
On Fri, Jul 6, 2012 at 6:41 PM, Daniel Farina 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 are the reaso
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 fr
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
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 wrote:
> * renamed auxiliary functions and moved it elog.c - header is new file
> "relerror.h"
In my revision, I've just added a pre-declaration and removed th
On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote:
> On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian 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 th
On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian 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 to see _all_
On tis, 2012-07-03 at 14:52 -0400, Tom Lane wrote:
> Peter Eisentraut 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
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.
> * Py
On Thu, Jun 14, 2012 at 10:01 PM, Heikki Linnakangas
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 it's the last field
> before CRC.
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 conve
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 sho
Excerpts from Alex's message of jue abr 19 17:06:05 -0300 2012:
> Peter Eisentraut 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 does
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 ha
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 Postgr
On Fri, Jul 6, 2012 at 4:00 PM, Dimitri Fontaine wrote:
> Robert Haas 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 a large remaining maintainability c
On Fri, Jul 6, 2012 at 3:29 PM, Dimitri Fontaine 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.
Oh, really? I tho
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, $3;
Robert Haas 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 to do before we c
On Fri, Jul 6, 2012 at 12:00 PM, Robert Haas wrote:
> On Fri, Jul 6, 2012 at 7:21 AM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> Attached is a incremental patch with a bunch of minor cleanups,
>>> including reverts of a few spurious white space changes. Could you
>>> merge this into
Robert Haas 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 trigger definition can
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 rig
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 chang
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 *w
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 PLy_elog()
Csaba Nagy 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)
To make changes to your
On 24 June 2012 04:01, Alvaro Herrera 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 RELKIND_RELATION and RELKIND_FORE
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
> > > wrote: I don't see the virtue of this in this
> > > case. Since the index is not unique, why no
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 p
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
> > 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
On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine wrote:
> Tom Lane 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
Tom Lane 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 objects. So we c
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane 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 =
format_function_arguments(finfo, func
On Mon, Jul 2, 2012 at 8:51 PM, Greg Smith wrote:
>
> 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 version
> to return
Yes, it's a bug and it needs to be applied !
On Tue, Jul 3, 2012 at 7:44 PM, Robert Haas wrote:
> On Tue, Jul 3, 2012 at 11:34 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jun 21, 2012 at 2:53 PM, Alexander Korotkov
>>> wrote:
I think we definitely should apply this patch before
Hi all,
> On Thu, Jun 28, 2012 at 5:16 AM, David E. Wheeler
> 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 and d
> in the inde
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
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 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 mig
39 matches
Mail list logo
