Josh Berkus wrote:
> if I, in one of my applications, accidentally defined something
> as having the range '('15:15:00','15:15:00')', I would *want* the
> database to through an error and not accept it.
I can agree with that, but I think that range '[15:15:00,15:15:00)'
should be valid as a ze
From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
On Behalf Of Tom Lane [t...@sss.pgh.pa.us]
Sent: Friday, February 11, 2011 7:35 PM
To: Dimitri Fontaine
Cc: David E. Wheeler; Robert Haas; Josh Berkus; pgsql-hackers@postgresql.or
Jeff Davis wrote:
> The philosophy is that they are essentially the "zero" value of
> any range type. Like the number zero, it allows closure over
> operations that would otherwise return an error.
Well, zero has a pretty well defined and easy to understand meaning.
How many ostriches do you h
On Fri, 2011-02-11 at 14:59 +0100, Michael Banck wrote:
> On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote:
> > Less narrow-minded interpretation of GPL requirements, perhaps.
> > (And yes, we have real lawyers on staff considering these issues.)
>
> Is their opinion public/can be made pub
On Fri, Feb 11, 2011 at 1:30 PM, Tom Lane wrote:
> In principle we are leaving it to the extension author to choose that.
> However, we're going to have to make a choice for the contrib modules,
> and I'll bet lunch that most people will follow whatever precedent we
> set with those. I was thinki
On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote:
> It's a nice, clean patch. However, it achieves that by targeting a smaller
> goal. Specifically, it omits:
>
> 1) Test cases and DEBUG messages sufficient to facilitate them
That was an intentional omission.
> 2) Skip rewrite for T -> constr
"David E. Wheeler" writes:
> Sounds good. One nit: can't we call the line in the control file "version"
> rather than "default_version"? I've been thinking of the control file as
> describing a release of an extension, which of course has a version, not a
> default version.
No --- in the curre
On 2/11/11 10:11 AM, Jeff Davis wrote:
> Thoughts? Do the benefits outweigh the costs?
I guess I'm having trouble tying the concept of empty ranges to any
reality external to the database.
For example, what would the time range:
'('15:15:00','15:15:00')'
... represent exactly? "A non-existant
On Fri, Feb 11, 2011 at 02:15:20PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
> > On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote:
> > > 3. The original tuple needs to be marked with the Cmax of the locking
> > >command, t
* Magnus Hagander (mag...@hagander.net) wrote:
> We may also have a problem in that libpq exposes OpenSSL structs,
> though. We actually return it as a void *, to make it possible to
> change, but there's no API in libpq to tell you what it is...
Ugh, yeah, that probably wasn't the best decision i
Robert Haas writes:
> On Fri, Feb 11, 2011 at 12:35 PM, Tom Lane wrote:
>> OK, let me see if I can summarize what I think we've agreed to:
>>
>> CREATE syntax is extended to
>>
>>CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
> It strikes me that if you used the sam
On Feb 11, 2011, at 9:35 AM, Tom Lane wrote:
> OK, let me see if I can summarize what I think we've agreed to:
>
> CREATE syntax is extended to
>
> CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
>
> If VERSION is not specified, v is taken from default_version in the
>
On Fri, Feb 11, 2011 at 19:13, Stephen Frost wrote:
> * Greg Smith (g...@2ndquadrant.com) wrote:
>> -Adding GnuTLS support to PostgreSQL would require solving several
>> code quality issues
>
> I'm curious about this, but I don't know that I've got time to dive into
> it and solve it. :/
Yeah, I
* Greg Smith (g...@2ndquadrant.com) wrote:
> -GNU libreadine is certainly never going to add an OpenSSL exemption
I really wish they would, that's just them being obnoxious- it's already
LGPL, after all..
> -If the OpenSSL project was going to switch to a reasonable license,
> they'd have done it
Do we want empty ranges?
The philosophy is that they are essentially the "zero" value of any
range type. Like the number zero, it allows closure over operations that
would otherwise return an error.
For instance, the number zero is useful because you can do things like:
f(x) = 5x + 3;
And even
> CREATE EXTENSION extname [ ( option [ , ... ] ) ]
>
> where option can be one of:
>
> SCHEMA blah
> VERSION blah
> FROM blah
+1
This also means that users don't have to remember the specific ordering
of the syntax, which is a big plus.
--
-- Josh Berkus
Josh Berkus wrote:
> I can imagine using all of these constructs in actual
> applications.
But which of them, if any, is an "empty range"?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Feb 11, 2011, at 10:06 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
>>> different default version name from what CREATE EXTENSION uses (unless
>
>> Yes. I see that as a good feature to have. s
On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
>>> different default version name from what CREATE EXTENSION uses (unless
>
>> Yes. I see that as a good feature to have.
On Fri, February 11, 2011 19:02, Josh Berkus wrote:
>
>> "empty range"
>> =
>> Zero length?
>> If so, is it fixed at some point, but empty?
>> '(x,x)'?
>> '[x,x)'?
>
> Neither of the above should be possible, I think. The expression "(x"
> logically excludes the expression "x
Hi Robert,
On Fri, Feb 11, 2011 at 10:27:11AM -0500, Robert Haas wrote:
> On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch wrote:
> > Done as attached. ?This preserves compatibility with our current handling of
> > composite type dependencies. ?The rest you've seen before.
>
> OK, I finally got back
On Feb 11, 2011, at 10:01 AM, Alex Hunsaker wrote:
>> That *looks* like it is decoding the input string, which it is, but
>> actually that will double utf8 encode your string. It does not seem to
>> in this case because we are dealing with all ascii input. The trick
>> here is its also telling per
On Fri, Feb 11, 2011 at 12:35 PM, Tom Lane wrote:
> OK, let me see if I can summarize what I think we've agreed to:
>
> CREATE syntax is extended to
>
> CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
It strikes me that if you used the same options syntax here that we're
On Feb 11, 2011, at 9:34 AM, Andrew Dunstan wrote:
> Is there an action item here? Is the documentation inadequate or inaccurate?
> If so, please make a suggestion for improved wording.
>
> I certainly expect the change to be covered in the release notes. You can
> check on the prominence given
Dimitri Fontaine writes:
> Tom Lane writes:
>> Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
>> different default version name from what CREATE EXTENSION uses (unless
> Yes. I see that as a good feature to have. stable and support looks
> like good default aliases for
On Feb 11, 2011, at 9:44 AM, Alex Hunsaker wrote:
> It is decoded... the input string "%C3%A9" actually is the _same_
> string utf-8, latin1 and SQL_ASCII decoded or not. Those are all ascii
> characters. Calling utf8::decode("%C3%A9") is essentially a noop.
No, it's not decoded. It doesn't matte
> "empty range"
> =
> Zero length?
> If so, is it fixed at some point, but empty?
> '(x,x)'?
> '[x,x)'?
Neither of the above should be possible, I think. The expression "(x"
logically excludes the expression "x)".
However, "[x,x]" would be valid, and would be a zero-length
On Fri, Feb 11, 2011 at 10:44, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 10:16, David E. Wheeler wrote:
> That *looks* like it is decoding the input string, which it is, but
> actually that will double utf8 encode your string. It does not seem to
> in this case because we are dealing with a
On 02/11/2011 12:36 PM, Robert Haas wrote:
On Fri, Feb 11, 2011 at 12:26 PM, Jeff Davis wrote:
On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote:
For what it's worth, my completely uninformed opinion is that
comparison operators shouldn't error out. I haven't read the patch so
I'm not su
* Robert Haas (robertmh...@gmail.com) wrote:
> Actually... wait a minute. Now that I'm thinking about this a little
> more, I'm not so convinced. If we leave this the way is, and just
> paper over the problem using the method Stephen and I both had in
> mind, then we could be streaming from a pos
Michael Banck wrote:
On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote:
Less narrow-minded interpretation of GPL requirements, perhaps.
(And yes, we have real lawyers on staff considering these issues.)
Is their opinion public/can be made public? This might possibly lead to
a r
Jeff Davis wrote:
> ">>" means "strictly right of"
> "<<" means "strictly left of"
> "-|-" means "adjacent" (touching but not overlapping)
>
> I'm open to suggestion about how those behave with empty ranges.
OK, that still leaves a lot to the imagination, though. To try to
clarify in *my* mi
On Fri, Feb 11, 2011 at 10:16, David E. Wheeler wrote:
> On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote:
> Like I said, the terminology is awful.
Yeah I use encode and decode to mean the same thing frequently :-(.
>> In the the cited case he was passing "%C3%A9" to uri_unescape() and
>> expe
On Fri, Feb 11, 2011 at 12:26 PM, Jeff Davis wrote:
> On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote:
>> For what it's worth, my completely uninformed opinion is that
>> comparison operators shouldn't error out. I haven't read the patch so
>> I'm not sure what those operators are defined to
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
If VERSION is not specified, v is taken from default_version in the
control file, or fail if that's not given either. We create
Tom Lane writes:
>> That's not exactly what happens here. There would be no "support"
>> version alias in the control file, so no way to upgrade to it, and
>> "support" would happen to be what ALTER EXTENSION foo UPDATE would
>> consider when you don't mention explicitly the target version.
>
>>
On 02/11/2011 12:16 PM, David E. Wheeler wrote:
[long discussion elided]
Is there an action item here? Is the documentation inadequate or
inaccurate? If so, please make a suggestion for improved wording.
I certainly expect the change to be covered in the release notes. You
can check on the
On Fri, Feb 11, 2011 at 12:25 PM, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost wrote:
>> Fujii, all,
>>
>> * Fujii Masao (masao.fu...@gmail.com) wrote:
>>> That logic exists because we'd like to check that newly-received WAL
>>> data is consistent with previous one by vali
On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote:
> For what it's worth, my completely uninformed opinion is that
> comparison operators shouldn't error out. I haven't read the patch so
> I'm not sure what those operators are defined to do, though.
">>" means "strictly right of"
"<<" means "s
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost wrote:
> Fujii, all,
>
> * Fujii Masao (masao.fu...@gmail.com) wrote:
>> That logic exists because we'd like to check that newly-received WAL
>> data is consistent with previous one by validating the header of new
>> WAL file. So since we need the he
On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote:
> I'd like to quibble with you over this point if I may. :-)
> Per perldoc: JSON::XS
> "utf8" flag disabled
> When "utf8" is disabled (the default), then
> "encode"/"decode" generate and expect Unicode strings ...
>
> So
> - If you are
Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
Hello,
First, thanks for the very thorough review.
> On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote:
> Incidentally, HeapTupleSatisfiesMVCC has some bits of code like this (not
> new):
>
> /* MultiXa
Robert Haas wrote:
>> Goodness... I picked up this patch the day before yesterday
>> because no-one was listed. That being said, if anyone else wants
>> to beat me to the punch of reviewing this, have at it! The more
>> eyes the merrier!
>
> Sorry, I didn't see when you'd picked it up. I was j
Dimitri Fontaine writes:
> Tom Lane writes:
>> Uh, not sure how you're envisioning that working? If it fails to find
>> an upgrade script path from the current version to whatever is default,
>> it will still fail to find any path after you explicitly tell it you
>> want to upgrade to that versi
Tom Lane writes:
>>> 1. If you pick the wrong FROM version, the upgrade script will almost
>>> certainly fail, because the objects won't exist or won't be in the state
>>> it expects (ie, not already members of the extension).
> IIRC, the current behavior is that C.O.R.F. on an existing function
>
On Fri, Feb 11, 2011 at 11:55 AM, Jeff Davis wrote:
> On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote:
>> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
>> > Updated patch.
>> >
>>
>> The operators << >> and -|- have the following behavior with empty
>> ranges:
>>
>> testdb=# select
Noah Misch wrote:
> I'd say, run them with this patch alone. The important thing is
> to not penalize existing COPY users.
Sounds good.
> Incidentally, the "did you want ... ?" was a genuine question. I
> see very little performance risk here, so the tests could be quite
> cursory, even ab
Tom Lane writes:
> After a bit of reflection I think we should stick with "default_version"
> as the parameter name in 9.1. If we want to open it up to allowing
> arbitrary version aliases later, we can let it accept "xxx_version" as
> defining an alias "xxx". That seems a lot safer than interpr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> $ which collateindex.pl
> /usr/bin/collateindex.pl
> $ rpm -qf /usr/bin/collateindex.pl
> docbook-style-dsssl-1.79-11.fc13.noarch
Ah-hah, thanks for that! Apparently on Debian it's docbook-dsssl that
contains it, and yes, it gets installed into /usr/bin (n
On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote:
> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> > Updated patch.
> >
>
> The operators << >> and -|- have the following behavior with empty ranges:
>
> testdb=# select '-'::int4range << range(200,300);
> ERROR: empty range
> testdb
Excerpts from Tom Lane's message of vie feb 11 13:49:33 -0300 2011:
> Stephen Frost writes:
> > * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> >> You might need "yum install openjade stylesheets" or similar packages
> >> and re-"configure".
>
> > I've got openjade, etc, installed, but I
Fujii, all,
* Fujii Masao (masao.fu...@gmail.com) wrote:
> That logic exists because we'd like to check that newly-received WAL
> data is consistent with previous one by validating the header of new
> WAL file. So since we need the header of new WAL file, we retreat the
> replication starting loca
Stephen Frost writes:
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> You might need "yum install openjade stylesheets" or similar packages
>> and re-"configure".
> I've got openjade, etc, installed, but I'm on Debian and it doesn't
> appear to include that collateindex.pl anywhere..
On Fri, Feb 11, 2011 at 10:31:08AM -0600, Kevin Grittner wrote:
> Robert Haas wrote:
> > Noah Misch wrote:
> >> From a functional and code structure perspective, I find this
> >> ready to commit. (I assume you'll drop the XXX: indent only
> >> comments on commit.) Kevin, did you want to do that
Dimitri Fontaine writes:
> Is there a test somewhere that when CREATE OR REPLACE FUNCTION
> runs from an extension's script at upgrade, the function must
> already be attached to the extension if it exists in the system?
> Ditto for views etc?
IIRC, the current behavior is that C.O.R.F. on an
Itagaki Takahiro wrote:
> Basically, we have no more tasks until the FDW core API is
> applied. COPY API and file_fdw patches are waiting for it.
This is something I've found confusing about this patch set, to the
point of not knowing what to test, exactly. The COPY API patch and
the patch-on
Dimitri Fontaine writes:
> Tom Lane writes:
>>> I can already hear people wanting version aliases instead. We could
>>> support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta'
>>> and maybe 'experimental'. Then rather than defining "current_version"
>>> authors would define any se
On Fri, Feb 11, 2011 at 11:22 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 08:45, Robert Haas wrote:
>> On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wrote:
>>> On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
> On 23/12/10 14:56, Jan Urbański wrote:
>>
On Fri, Feb 11, 2011 at 11:31 AM, Itagaki Takahiro
wrote:
> On Sat, Feb 12, 2011 at 01:12, Robert Haas wrote:
>> On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch wrote:
>>> From a functional and code structure perspective, I find this ready to
>>> commit.
>>> (I assume you'll drop the XXX: indent onl
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > If we're going to abbreviate transaction, I'd vote for txn over tran,
> > but I think Stephen's point that this is already a lost cause may have
> > some validity. Not sure what other people think.
I agree w/ reducing that particul
Robert Haas wrote:
> Noah Misch wrote:
>> From a functional and code structure perspective, I find this
>> ready to commit. (I assume you'll drop the XXX: indent only
>> comments on commit.) Kevin, did you want to do that performance
>> testing you spoke of?
>
> OK, so is this Ready for Committ
On Sat, Feb 12, 2011 at 01:12, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch wrote:
>> From a functional and code structure perspective, I find this ready to
>> commit.
>> (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did
>> you
>> want to do that per
On Fri, Feb 11, 2011 at 11:17 AM, Itagaki Takahiro
wrote:
> Did you measure the actual cost in the real world? If we are using
> such a sensitive parser, it should be a problem even without the patch.
It *is* a problem without the patch!
>> Adding unnecessary keywords is something to be avoided.
Robert Haas writes:
> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
> wrote:
>> Should we abbreviate something there? max_pred_locks_per_tran,
>> maybe?
> If we're going to abbreviate transaction, I'd vote for txn over tran,
> but I think Stephen's point that this is already a lost cause may
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote:
> > Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl',
> > apparently..).
>
> You might need "yum install openjade stylesheets" or similar packages
> and re-"configure".
I'
On Fri, Feb 11, 2011 at 08:45, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wrote:
>> On 06/02/11 20:12, Jan Urbański wrote:
>>> On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
> Here's a patch implementing traceback support for PL/Pytho
Tom Lane writes:
CREATE EXTENSION foo [ VERSION targetversion ] [ FROM
oldversion ]
I came to the same conclusion but added my version aliases idea in
there so that it could maybe be easy for the user not to confuse
things.
I still think that free form version aliases and some de
On 11-02-10 05:20 AM, Jan Urbański wrote:
D'oh, I was thinking about whether it's safe to skip the internal
subxact if you're in an implicit one and somehow I always convinced
myself that since you eventually close the explicit one, it is.
Obviously my testing wasn't enough :( Attaching an upda
On Sat, Feb 12, 2011 at 00:50, Tom Lane wrote:
> Robert Haas writes:
>> Right, but making the parser slower has a cost, too.
>> ScanKeywordLookup() is already a hotspot in some workloads, and
>> there's overhead buried in the bison parser, too.
>
> Yeah. Keep in mind that a bison parser fundamen
On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch wrote:
> From a functional and code structure perspective, I find this ready to commit.
> (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did
> you
> want to do that performance testing you spoke of?
OK, so is this Ready for Comm
* Robert Haas (robertmh...@gmail.com) wrote:
> Yeah. The root cause of this problem is that the way psql handles
> tabular output with a few very wide rows stinks.
True, but it would be kinda nice to support multi-line configuration
variables. I still vote for that being "not required to get thi
On Fri, Feb 11, 2011 at 10:49 AM, Jan Urbański wrote:
> On 11/02/11 16:43, Robert Haas wrote:
>> On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wrote:
That's it for now. It is an exciting feature and plpython will be the
first language to think of when you're building "object database" if
On Fri, Feb 11, 2011 at 08:47, Robert Haas wrote:
> On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
>> 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 invalid
On Fri, Feb 11, 2011 at 10:52 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
>> > Should we abbreviate something there? max_pred_locks_per_tran,
>> > maybe?
>>
>> If we're going to abbreviate transaction, I'd vote for tx
On Fri, Feb 11, 2011 at 10:51 AM, Jan Urbański wrote:
> On 11/02/11 16:47, Robert Haas wrote:
>> On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
>>> On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
>>> It seems a bit heavy handed to invalidate and remake the entire
>>> plpython function w
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
> > Should we abbreviate something there? max_pred_locks_per_tran,
> > maybe?
>
> If we're going to abbreviate transaction, I'd vote for txn over tran,
> but I think Stephen's point that this is alread
On Fri, Feb 11, 2011 at 10:45 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed wrote:
>> > And tried the patch on Windows and Linux and it works for me.
>>
>> Does this need more review, or should it be marked "Ready for Comm
On 11/02/11 16:47, Robert Haas wrote:
> On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
>> On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
>> It seems a bit heavy handed to invalidate and remake the entire
>> plpython function whenever we hit this case. I think we could get away
>> with s
Robert Haas writes:
> Right, but making the parser slower has a cost, too.
> ScanKeywordLookup() is already a hotspot in some workloads, and
> there's overhead buried in the bison parser, too.
Yeah. Keep in mind that a bison parser fundamentally runs off a
two-dimensional array: one axis is pars
YAMAMOTO Takashi wrote:
> 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.
Is this a hypothetical risk b
On 11/02/11 16:43, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wrote:
>>> That's it for now. It is an exciting feature and plpython will be the
>>> first language to think of when you're building "object database" if
>>> this feature is in. The design here will affect followi
On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
> 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 a
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wrote:
> On 06/02/11 20:12, Jan Urbański wrote:
>> On 27/01/11 22:58, Jan Urbański wrote:
>>> On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed wrote:
> > And tried the patch on Windows and Linux and it works for me.
>
> Does this need more review, or should it be marked "Ready for Committer"?
I think it can be marked ready for committer. Heikk
On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wrote:
>> That's it for now. It is an exciting feature and plpython will be the
>> first language to think of when you're building "object database" if
>> this feature is in. The design here will affect following pl/perl and
>> other so it is important
On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed wrote:
> Stephen Frost!
> I have modified the code to use ADD_STARTUP_OPTION instead of writing code
> again.
> And tried the patch on Windows and Linux and it works for me.
Does this need more review, or should it be marked "Ready for Committer"?
--
=?ISO-8859-1?Q?Anssi_K=E4=E4ri=E4inen?= writes:
> The above command assumes there is only one unpackaged version from
> which users might update from. Is that what is wanted? I am wondering if
> FROM OLD should be FROM OLD VERSION version (or better: FROM UNPACKAGED
> VERSION version). This wou
On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
wrote:
>>Stephen Frost wrote:
>
>> That, plus the length of max_predicate_locks_per_transaction,
>> would make 'show all;' go beyond 80 characters even if we took out
>> the description
>
> Should we abbreviate something there? max_pred_locks_per_
On Fri, Feb 4, 2011 at 9:11 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine wrote:
>>> In math class, maybe. But in programming, no. Multiset is a
>>> datatype. Array is a different datatype. There is no reason why we
>>> need to clutter our parser with extra keyw
>Stephen Frost wrote:
> That, plus the length of max_predicate_locks_per_transaction,
> would make 'show all;' go beyond 80 characters even if we took out
> the description
Should we abbreviate something there? max_pred_locks_per_tran,
maybe?
-Kevin
--
Sent via pgsql-hackers mailing list
On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch wrote:
> On Wed, Jan 26, 2011 at 07:31:40AM -0500, Robert Haas wrote:
>> I'd also suggest that this big if-block you changed to a case
>> statement could just as well stay as an if-block. There are only
>> three cases, and we want to avoid rearranging t
Robert Haas writes:
> On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> I still think you might be over-designing this. Upgrading from the
>>> pre-extension world doesn't need to be elegant; it just has to work.
>>
>> Allow me to disagree here.
> Sure, but
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think it's entirely stupid to worry about this completely
> screwing up the output of "SHOW ALL" on people using 80-character
> terminal windows. I haven't checked, but if it renders the output
> totally unreadable then I think we should try t
On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I still think you might be over-designing this. Upgrading from the
>> pre-extension world doesn't need to be elegant; it just has to work.
>
> Allow me to disagree here. The main use case is not supporting users
>
On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> Updated patch.
>
The operators << >> and -|- have the following behavior with empty ranges:
testdb=# select '-'::int4range << range(200,300);
ERROR: empty range
testdb=# select '-'::int4range >> range(200,300);
ERROR: empty range
testdb=#
Robert Haas writes:
> I still think you might be over-designing this. Upgrading from the
> pre-extension world doesn't need to be elegant; it just has to work.
Allow me to disagree here. The main use case is not supporting users
that upgrade with extensions to 9.1, but to allow people working o
On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote:
> Less narrow-minded interpretation of GPL requirements, perhaps.
> (And yes, we have real lawyers on staff considering these issues.)
Is their opinion public/can be made public? This might possibly lead to
a re-evaluation of the situation
Greg,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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
> >
On Fri, Feb 11, 2011 at 12:15 AM, Tom Lane wrote:
> "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 s
I think that Acai berry supplements are used as part of various pyramid schemes.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
101 - 200 of 209 matches
Mail list logo
