On Thu, Feb 10, 2011 at 21:53, David E. Wheeler wrote:
> On Feb 10, 2011, at 5:28 PM, Alex Hunsaker wrote:
>> The other thing that changed is non UTF-8 databases now also get
>> character semantics. That is we convert from the database encoding
>> into utf8 and visa versa on output. That probably
On Wed, Feb 09, 2011 at 10:55:05AM +0900, Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas
> wrote:
> > On Mon, Feb 7, 2011 at 21:17, Noah Misch wrote:
> >> The message does not show which foreign table yielded the error. ??We
> >> could evade
> >> the problem in this c
On Feb 10, 2011, at 9:15 PM, Tom Lane wrote:
> Hmm, you're right. The word bootstrap implies that we're starting from
> nothing, which is exactly what we're *not* doing (starting from nothing
> is the easy "clean install" case). By the same token, FROM NOTHING
> isn't the right phrase either. A
"David E. Wheeler" writes:
> On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
>> (I'm not wedded to the phrase "FROM OLD" in particular, but it does
>> reuse already existing keywords. Also, maybe it'd be better to reserve
>> a version string such as "old" or "bootstrap", so that the bootstrap
>> scr
On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
> I like this because (a) it's one less step, and one less concept for
> users to deal with, and (b) it's much harder to screw up. If you forget
> FROM OLD when you needed it, the CREATE will fail with "object already
> exists" errors. If you use FROM
On Feb 10, 2011, at 5:28 PM, Alex Hunsaker wrote:
> Hrm? For UTF-8 databases, in practice, nothing should have changed--
> we already passed strings in as utf8. What I fixed was some corner
> cases where some strings did not always have character semantics. See
> The "Unicode Bug" and "Forcing Uni
On Thu, Feb 10, 2011 at 10:30 PM, Greg Smith wrote:
> 3) The existing write spreading code in the background writer needs to be
> overhauled, too, before spreading the syncs around is going to give the
> benefits I was hoping for.
I've been thinking about this problem a bit. It strikes me that t
Looks like it's time to close the book on this one for 9.1
development...the unfortunate results are at
http://www.2ndquadrant.us/pgbench-results/index.htm Test set #12 is the
one with spread sync I was hoping would turn out better than #9, the
reference I was trying to improve on. TPS is abo
Greg Smith writes:
> Poking around a bit more, I just discovered another possible approach is
> to use erand48 instead of rand in pgbench, which is either provided by
> the OS or emulated in src/port/erand48.c That's way more resolution
> than needed here, given that 2^48 pgbench accounts woul
"David E. Wheeler" writes:
> On Feb 10, 2011, at 4:11 PM, Tom Lane wrote:
>> It's to tell it to create an empty extension in preparation for
>> absorbing pre-existing objects from an old-style contrib module.
>> See what I mean? WRAPPER is not a useful keyword here.
> Reminds me of creating a "s
On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder wrote:
> So what you're suggesting is that the plpgsql code is causing the issues?
> Are there any indications about how I could re-write this code? The
> important thing for me is to have the aforementioned signature of the
> plpgsql function with one U
Stephen Frost wrote:
Just wondering, did you consider just calling random() twice and
smashing the result together..?
I did. The problem is that even within the 32 bits that random()
returns, it's not uniformly distributed. Combining two of them isn't
really going to solve the distributi
On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
> On 27/01/11 22:42, Jan Urbański wrote:
>> On 23/12/10 14:50, Jan Urbański wrote:
>>> Here's a patch implementing properly invalidating functions that have
>>> composite type arguments after the type changes, as mentioned in
>>> http://archives.po
On Thu, Feb 10, 2011 at 16:28, David E. Wheeler wrote:
> Hackers,
>
> With regard to this (very welcome) commit:
>
>> commit 50d89d422f9c68a52a6964e5468e8eb4f90b1d95
>> Author: Andrew Dunstan
>> Date: Sun Feb 6 17:29:26 2011 -0500
>>
>> Force strings passed to and from plperl to be in UTF8
On Thu, Feb 10, 2011 at 6:21 PM, Nicolas Barbier
wrote:
> 2011/2/10 mac_man2...@yahoo.it :
>
>> Which operations invoke the sorting algorithms implemented in the sorting
>> module (tuplesort.c) ?
>> Of course, one of those operations invoking sorting is the ORDER BY clause
>> and the DISTINCT too.
On Thu, Feb 10, 2011 at 6:50 PM, Tom Lane wrote:
> Since we've agreed that there should be a version-to-install option
> in CREATE EXTENSION, it seems to me that a workable solution is to
> have a special convention for an "empty extension" version name.
> Let's suppose that we choose the empty st
hi,
it seems that PredicateLockTupleRowVersionLink sometimes create
a loop of targets (it founds an existing 'newtarget' whose nextVersionOfRow
chain points to the 'oldtarget') and it later causes
CheckTargetForConflictsIn loop forever.
YAMAMOTO Takashi
--
Sent via pgsql-hackers mailing list (p
On Feb 10, 2011, at 4:11 PM, Tom Lane wrote:
> It's to tell it to create an empty extension in preparation for
> absorbing pre-existing objects from an old-style contrib module.
> See what I mean? WRAPPER is not a useful keyword here.
Reminds me of creating a "shell type" so you can create I/O f
"David E. Wheeler" writes:
> On Feb 10, 2011, at 3:50 PM, Tom Lane wrote:
>> First off, I don't much care for the name "CREATE WRAPPER EXTENSION".
> What's the WRAPPER bit for? I've forgotten.
It's to tell it to create an empty extension in preparation for
absorbing pre-existing objects from an
On Feb 10, 2011, at 3:50 PM, Tom Lane wrote:
> It seems that we've mostly got consensus on the ideas of having a separate
> script file for each installable version of an extension, and for each
> basic version-upgrade action, with version numbers embedded in the file
> names so that the control f
It seems that we've mostly got consensus on the ideas of having a separate
script file for each installable version of an extension, and for each
basic version-upgrade action, with version numbers embedded in the file
names so that the control files don't need to be involved in identifying
what's w
On 02/10/2011 06:36 PM, Stephen Frost wrote:
* Daniel Farina (drfar...@acm.org) wrote:
I have to admit, this change in debian packaging -- which I have
noticed, and not a little -- makes my hands angry. I considered
looking into the problem, but were I doing it, I would have considered
teachin
* Daniel Farina (drfar...@acm.org) wrote:
> I have to admit, this change in debian packaging -- which I have
> noticed, and not a little -- makes my hands angry. I considered
> looking into the problem, but were I doing it, I would have considered
> teaching psql to support NSS or GnuTLS as totally
Hackers,
With regard to this (very welcome) commit:
> commit 50d89d422f9c68a52a6964e5468e8eb4f90b1d95
> Author: Andrew Dunstan
> Date: Sun Feb 6 17:29:26 2011 -0500
>
> Force strings passed to and from plperl to be in UTF8 encoding.
>
> String are converted to UTF8 on the way int
2011/2/10 mac_man2...@yahoo.it :
> Which operations invoke the sorting algorithms implemented in the sorting
> module (tuplesort.c) ?
> Of course, one of those operations invoking sorting is the ORDER BY clause
> and the DISTINCT too.
>
> Moreover, the Merge Join should be implemented invoking sor
Excerpts from Joshua D. Drake's message of jue feb 10 19:34:31 -0300 2011:
> Hello,
>
> Per:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
O, the joy of having people mess up with legal stuff that nobody cares
about creating endless work for everyone.
--
Álvaro Herrera
The Postg
Andrew Dunstan writes:
> I'll be happy if you do, but why haven't I haven't noticed, say, RedHat
> taking this line?
Less narrow-minded interpretation of GPL requirements, perhaps.
(And yes, we have real lawyers on staff considering these issues.)
libedit is a long way from being ready to repla
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we should embed the version number in the script file name,
> What I don't like in that is that this restrict what the version strings
> can look like. In debian for example it's pretty common to use the ~
> separator, because 1.0~alpha1 <
On 02/10/2011 05:34 PM, Joshua D. Drake wrote:
Hello,
Per:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
It seems we may have a problem to consider. As far as I know, we are the
only major platform that supports libedit but our default is readline.
Unfortunately readline is not com
On Thu, Feb 10, 2011 at 2:34 PM, Joshua D. Drake wrote:
> Hello,
>
> Per:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>
> It seems we may have a problem to consider. As far as I know, we are the
> only major platform that supports libedit but our default is readline.
> Unfortunatel
>> I don't see how that affects my point? You can spell "1.0" as "0.1"
>> and "1.1" as "0.2" if you like that kind of numbering, but I don't
>> see that that has any real impact. At the end of the day an author is
>> going to crank out a series of releases, and if he cares about people
>> using t
Alvaro Herrera writes:
> I wrote such a patch some time ago but never applied it ...
> http://archives.postgresql.org/message-id/20091116162531.ga3...@alvh.no-ip.org
> I still wonder if it's useful enough to be applied. Would it solve your
> use case?
Needs to be fixed to behave sanely for the t
Hi.
Which operations invoke the sorting algorithms implemented in the
sorting module (tuplesort.c) ?
Of course, one of those operations invoking sorting is the ORDER BY
clause and the DISTINCT too.
Moreover, the Merge Join should be implemented invoking sorting.
Is there any other operation
David Christensen writes:
> I assume this has already been discussed and rejected (or it wouldn't still
> be an issue), but what's wrong with the equivalent of \i in the successive
> .sql upgrade files? Or is the server running the scripts itself and no
> equivalent include feature exists in r
Hello,
Per:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
It seems we may have a problem to consider. As far as I know, we are the
only major platform that supports libedit but our default is readline.
Unfortunately readline is not compatible with OpenSSL (apparently?)
licensing.
This
Excerpts from Pavel Stehule's message of sáb ene 29 16:56:40 -0300 2011:
> 2011/1/29 Tom Lane :
> > The less crocky way to do that is to use SPI_palloc() for something that
> > should be allocated in the outer context.
>
> I understand. Is there some way, where I can use a cstring_to_text
> funct
On Thu, Feb 10, 2011 at 11:29:43AM -0300, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of jue feb 10 07:58:16 -0300 2011:
>
> > One thing I was thinking of was that we could add a global make
> > maintainer-check target (a name I picked up from other projects)
> > which would r
On Thu, Feb 10, 2011 at 09:16:09PM +0200, Peter Eisentraut wrote:
> On tor, 2011-02-10 at 10:40 -0800, David Fetter wrote:
> > I think all such checks belong in .git/hooks/pre-commit, and need
> > to be as cross-platform as needed for committers. Would a
> > *n*x-based version do for a start?
>
>
Dimitri Fontaine writes:
> "David E. Wheeler" writes:
>> Yes, I think that this is a great solution. I only have to create on
>> upgrade script for each release, and I don't have to worry about
>> concatenating anything or be required to change my versioning
>> algorithm.
> You still have to mak
On Thu, Feb 10, 2011 at 9:38 PM, Tom Lane wrote:
>> Well, the difference is that loose objects are just on my system,
>> whereas extensions are supposed to work on anybody's system. I'm not
>> clear that it's possible to write an extension that depends on a
>> relocatable extension in a sensible
On Feb 10, 2011, at 1:38 PM, Tom Lane wrote:
> I don't deny that there are risks here. But I think the value of being
> able to move an extension when it is safe outweighs the difficulty that
> sometimes it isn't safe. I think we can leave making it safer as a
> topic for future investigation.
>
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane wrote:
>> Again, it's not really any different from the case where the dependent
>> objects are "loose" rather than members of an extension.
> Well, the difference is that loose objects are just on my system,
> whereas extensions ar
"David E. Wheeler" writes:
> Yes, I think that this is a great solution. I only have to create on
> upgrade script for each release, and I don't have to worry about
> concatenating anything or be required to change my versioning
> algorithm.
You still have to make sure that the C code remains com
Robert Haas writes:
> Well, the difference is that loose objects are just on my system,
> whereas extensions are supposed to work on anybody's system. I'm not
> clear that it's possible to write an extension that depends on a
> relocatable extension in a sensible way. If it is, objection
> withd
On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>
> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>> On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
>>
>>> On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin
>>> wrote:
What was actually broken in encode_array_literal support of composite
On 11-02-10 03:13 PM, Jan Urbański wrote:
On 10/02/11 20:24, Peter Eisentraut wrote:
Here is the rest of my review.
Submission Review
---
Patch applies cleanly.
Documentation is still outstanding but Jan has promised it soon.
Usability Review
---
We don't have
On Feb 10, 2011, at 1:22 PM, Tom Lane wrote:
> Well, okay, let's go with that plan then. If we don't need to assume
> anything more than equality of version names being meaningful, I think
> chaining update scripts automatically should solve most of the
> complaints here. People who really want
On 02/08/2011 08:37 PM, Andrew Dunstan wrote:
On 02/07/2011 11:30 PM, Robert Haas wrote:
On Tue, Dec 28, 2010 at 9:23 PM, Karl Lehenbauer
wrote:
On Dec 28, 2010, at 7:29 PM, Tom Lane wrote:
This patch appears to be changing a whole lot of stuff that in fact
pg_indent has never changed, s
On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane wrote:
>> The real issue is what happens when you want to install
>> extension A, which depends on extensions B, C, and D, and B, C, and D
>> are all in non-standard locations. Does that have any chance of
>> working under the system we're proposing?
>
>
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane wrote:
>> Hmm. The problem with that is that once there are large numbers of
>> intermediate versions, the number of potential paths grows
>> exponentially.
> It's certainly not exponential i.e. O(2^n) or something of that form.
>
On Thu, Feb 10, 2011 at 4:14 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> No, you have to get *those other module authors* to make *their*
>> extensions not relocatable so that you can depend on them.
>
> Just tell me exactly in which world an extension's author is setting up
> the depend
Tom Lane writes:
> I don't think it's appropriate to hold extensions to a
> higher standard than we do loose objects --- especially when it takes
> superuser privileges to break things by moving an extension but not to
> break them by moving loose objects.
FWIW, +1.
Regards,
--
Dimitri Fontaine
On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote:
>>> The design as I sketched it didn't need to make any assumptions at all
>>> about the meaning of the version identifiers. But if you were willing
>>> to assume that the
Robert Haas writes:
> No, you have to get *those other module authors* to make *their*
> extensions not relocatable so that you can depend on them.
Just tell me exactly in which world an extension's author is setting up
the dependencies in the 'required' property and yet fails to realise
that tho
Hi,
Tom Lane writes:
> I spent some time reviewing this thread. I think the major point that's
Thanks for doing that, we badly needed someone without an horse in this
race to do that and finish the design.
> So I believe that it'd be a good idea if it were possible for an extension
> author to
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote:
>> The design as I sketched it didn't need to make any assumptions at all
>> about the meaning of the version identifiers. But if you were willing
>> to assume that the identifiers are comparable/sortable by some rule,
> You
On Thu, Feb 10, 2011 at 3:46 PM, David E. Wheeler wrote:
> On Feb 10, 2011, at 12:07 PM, Robert Haas wrote:
>
>> You don't need them to be sortable. You just need them to be
>> comparable, and equality seems like a plenty good enough comparison
>> rule. You can compute the shortest chain of upgr
Robert Haas writes:
> On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane wrote:
>> Now, if you want to argue that moving an extension after the fact (ALTER
>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
>> argue very hard. Do you want to propose ripping that out? But
>> relocating
On Feb 10, 2011, at 12:07 PM, Robert Haas wrote:
> You don't need them to be sortable. You just need them to be
> comparable, and equality seems like a plenty good enough comparison
> rule. You can compute the shortest chain of upgrade scripts that can
> take you from the current version to the
On Feb 10, 2011, at 12:02 PM, Tom Lane wrote:
> Oh, I see, you're just saying that it's not unlikely somebody could find
> himself with dozens of minor releases all being supported. Yeah, he'd
> then really need to provide shortcut upgrade scripts, and
> building/maintaining those would be a pain
On Thu, Feb 10, 2011 at 3:33 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Now, if you want to argue that moving an extension after the fact (ALTER
>>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
>>> argue very hard. Do you want to propose ripping that out? But
>>
Robert Haas writes:
>> Now, if you want to argue that moving an extension after the fact (ALTER
>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
>> argue very hard. Do you want to propose ripping that out? But
>> relocating at first install doesn't seem horrible.
Either an
On 10/02/11 20:24, Peter Eisentraut wrote:
> On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote:
>> On 27/01/11 23:24, Jan Urbański wrote:
>>> On 11/01/11 12:20, Jan Urbański wrote:
On 11/01/11 01:27, Tom Lane wrote:
> Hannu Krosing writes:
>> On 10.1.2011 17:20, Jan Urbański wrote
On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
>>> I don't see how that affects my point? You can spell "1.0" as "0.1"
>>> and "1.1" as "0.2" if you like that kind of numbering, but I don't
>>> see that that has any
On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane wrote:
> General opinion around Red Hat is relocatable RPMs don't work. But
> pushing a set of functions from one schema to another is a very much
> narrower problem than what an RPM has to deal with, so I'm not convinced
> that the analogy holds.
>
> Now
"David E. Wheeler" writes:
> On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
>> I don't see how that affects my point? You can spell "1.0" as "0.1"
>> and "1.1" as "0.2" if you like that kind of numbering, but I don't
>> see that that has any real impact. At the end of the day an author is
>> goin
On Feb 10, 2011, at 11:21 AM, Tom Lane wrote:
>> It will certainly mess up syntax highlighting and matching bracket detection
>> in pretty much all text editors...
>
> Yeah. It's a cute-looking notation but surely it will cause many more
> problems than it's worth. I agree with Robert's suggest
Robert Haas writes:
> On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane wrote:
>> requires, relocatable and schema: These are problematic, because it's not
>> out of the question that someone might want to change these properties
>> from one version to another. But as things are currently set up, we mus
On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin wrote:
What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal composite-type constants, e
On Feb 10, 2011, at 10:41 AM, Jeff Davis wrote:
> This might solve the constructor problem nicely if we could do things
> like:
> RANGE[10,20)
> But I have a feeling that will either cause a bizarre problem with the
> grammar, or someone will think it's not very SQL-like.
I like it a lot better
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
> I'm not really addressing that in this proposal. You could imagine
> supporting all the extension versions in one .so, or you could have one
> per version (meaning the upgrade scripts would have to CREATE OR REPLACE
> all the C functions to re-point
Josh Berkus writes:
>> You basically need the variable, the entry in the appropriate array in
>> guc.c, and some documentation (at least if you'd like anyone else to
>> ever use the code). Try looking at some past patches that added GUCs
>> similar to yours.
> For completeness, it would also be
"David E. Wheeler" writes:
> +1. I assume there will be some way to build versioned shared object
> libraries too, then?
I'm not really addressing that in this proposal. You could imagine
supporting all the extension versions in one .so, or you could have one
per version (meaning the upgrade sc
On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote:
> On 27/01/11 23:24, Jan Urbański wrote:
> > On 11/01/11 12:20, Jan Urbański wrote:
> >> On 11/01/11 01:27, Tom Lane wrote:
> >>> Hannu Krosing writes:
> On 10.1.2011 17:20, Jan Urbański wrote:
> > I changed that patch to use Perl ins
Florian Pflug writes:
>> This might solve the constructor problem nicely if we could do things
>> like:
>> RANGE[10,20)
>> But I have a feeling that will either cause a bizarre problem with the
>> grammar, or someone will think it's not very SQL-like.
> It will certainly mess up syntax highlighti
On tor, 2011-02-10 at 10:40 -0800, David Fetter wrote:
> I think all such checks belong in .git/hooks/pre-commit, and need to
> be as cross-platform as needed for committers. Would a *n*x-based
> version do for a start?
I think as a matter of principle, the only things that belongs into git
hooks
> This might solve the constructor problem nicely if we could do things
> like:
> RANGE[10,20)
> But I have a feeling that will either cause a bizarre problem with the
> grammar, or someone will think it's not very SQL-like.
It will certainly mess up syntax highlighting and matching bracket dete
On 08.02.2011 20:53, Robert Haas wrote:
That having been said, there is at least one part of this patch which
looks to be in pretty good shape and seems independently useful
regardless of what happens to the rest of it, and that is the code
that sends replies from the standby back to the primary.
2011/2/10 Josh Berkus :
>
>> You basically need the variable, the entry in the appropriate array in
>> guc.c, and some documentation (at least if you'd like anyone else to
>> ever use the code). Try looking at some past patches that added GUCs
>> similar to yours.
>
> For completeness, it would al
On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane wrote:
> requires, relocatable and schema: These are problematic, because it's not
> out of the question that someone might want to change these properties
> from one version to another. But as things are currently set up, we must
> know these things befo
> You basically need the variable, the entry in the appropriate array in
> guc.c, and some documentation (at least if you'd like anyone else to
> ever use the code). Try looking at some past patches that added GUCs
> similar to yours.
For completeness, it would also be good to add rows to the pg
On Feb 10, 2011, at 10:26 AM, Tom Lane wrote:
> 1. Choose the newest available version.
> 2. Let the control file specify which version is the default.
> I think I prefer #2 because it avoids needing a rule for comparing
> version identifiers, and it caters to the possibility that the
On Thu, Feb 10, 2011 at 1:41 PM, Jeff Davis wrote:
> This might solve the constructor problem nicely if we could do things
> like:
> RANGE[10,20)
> But I have a feeling that will either cause a bizarre problem with the
> grammar, or someone will think it's not very SQL-like.
I think won't cause
On Thu, 2011-02-10 at 13:07 -0500, Robert Haas wrote:
> According to our documentation[1], RANGE is reserved in SQL:2008 and
> SQL:2003, which makes it more imaginable to reserve it than it would
> be otherwise.
Oh, interesting.
> I believe that in a previous email you mentioned that
> you were h
On Thu, Feb 10, 2011 at 12:58:16PM +0200, Peter Eisentraut wrote:
> On ons, 2011-02-09 at 08:00 -0800, David Fetter wrote:
> > On Wed, Feb 09, 2011 at 01:17:06PM +, Bruce Momjian wrote:
> > > Remove more SGML tabs.
> >
> > Perhaps we should see about putting something in .git/hooks/pre-commit
On Thu, Feb 10, 2011 at 1:23 PM, Heikki Linnakangas
wrote:
> On 10.02.2011 20:01, Peter Eisentraut wrote:
>>
>> On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote:
>>>
>>> I originally put it there so that I wouldn't mix up data directories
>>> with a patch I'm reviewing, but I agree that it seem
I spent some time reviewing this thread. I think the major point that's
not received adequate discussion is this: the design assumes that there's
just one "current version" of any extension, and that's not good enough.
David Fetter was trying to make that point upthread but didn't seem to
convince
On Thu, 2011-02-10 at 09:46 -0500, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 7:58 PM, Jeff Davis wrote:
> > On the flip side, if we don't provide review to WIP patches during the
> > 3rd commitfest, how do we expect to get anything close to committable on
> > the 1st commitfest of the next cycle
On 10.02.2011 20:01, Peter Eisentraut wrote:
On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote:
I originally put it there so that I wouldn't mix up data directories
with a patch I'm reviewing, but I agree that it seems easier this way.
FWIW, I disagree with Tom and do recommend putting the c
On Thu, 2011-02-10 at 15:38 +0100, Erik Rijkers wrote:
> I've removed the change to catversion.h (18 lines, starting at 4985) from the
> patch file; then it
> applies cleanly.
I should mention that the last patch changed the representation to be
more compact. So, if you have any existing test dat
On Wed, Feb 9, 2011 at 2:09 AM, Jeff Davis wrote:
> That's how arrays do it: there's a special Expr node that represents an
> array expression. Maybe the same thing could be used for range types,
> but I fear that there may be some grammar conflicts. I doubt we'd want
> to fully reserve the keywor
On tor, 2011-02-10 at 09:28 -0800, Jeff Davis wrote:
> I originally put it there so that I wouldn't mix up data directories
> with a patch I'm reviewing, but I agree that it seems easier this way.
FWIW, I disagree with Tom and do recommend putting the catversion change
in the patch.
--
Sent via
On Thu, 2011-02-10 at 12:04 -0500, Tom Lane wrote:
> "Erik Rijkers" writes:
> > On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> >> Updated patch.
>
> > I just wanted to mention that this latest patch doesn't quite apply as-is,
> > because of catversion changes.
>
> Just a note: standard pra
"Erik Rijkers" writes:
> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
>> Updated patch.
> I just wanted to mention that this latest patch doesn't quite apply as-is,
> because of catversion changes.
Just a note: standard practice is for submitted patches to *not* touch
catversion.h. The co
Tom Lane writes:
> That would be rejected because you're not allowed to drop an individual
> member object of an extension. (And no, I don't want to have a kluge in
> dependency.c that makes that test work differently when
> creating_extension.)
Fair enough, all the more as soon as we have ALTER
=?ISO-8859-7?B?yNzt7/Ig0OHw4fDd9PHv9Q==?= writes:
> I am an MSc student in the department of Informatics and
> Telecommunications of the University of Athens and as part of my
> thesis I am examining a new path/plan cost model for DB optimizers. I
> have successfully changed the optimizer of
Dimitri Fontaine writes:
> Tom Lane writes:
>> Actually, it occurs to me that the need for ALTER EXTENSION DROP could
>> be upon us sooner than we think. The cases where an extension upgrade
>> script would need that are
>> (1) you want to remove some deprecated piece of the extension's API;
>>
Tom Lane writes:
> Actually, it occurs to me that the need for ALTER EXTENSION DROP could
> be upon us sooner than we think. The cases where an extension upgrade
> script would need that are
> (1) you want to remove some deprecated piece of the extension's API;
> (2) you want to remove some no-lo
On Thu, Feb 10, 2011 at 10:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't
>>> add the object to multiple extensions; and it has a natural inverse,
>>> ALTER EXTENSION DROP.
Robert Haas writes:
> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't
>> add the object to multiple extensions; and it has a natural inverse,
>> ALTER EXTENSION DROP. I am not necessarily suggesting that we will ever
>> all
1 - 100 of 135 matches
Mail list logo
