Tom Lane writes:
> My feeling about this is that we should recommend that version
> identifiers be limited to ASCII letters, digits, dots, and underscore,
> but assume that extension authors are adults and can grasp the risks
> of using other characters. We should not be in the business of trying
Tom Lane writes:
> Actually, I was having second thoughts about that while at dinner. What
> is the value of separating the bootstrap-an-extension-from-old-objects
> operation into two steps? It's certainly not convenient for users, and
> I don't see that the intermediate state with an empty ext
Tom Lane writes:
> First off, I don't much care for the name "CREATE WRAPPER EXTENSION".
> WRAPPER is a misnomer in this case --- it's not wrapping anything.
> I think Dimitri stated that he chose WRAPPER just because it was an
> already existing keyword, but that isn't much of an excuse.
Let's g
On 10/02/11 22:26, Steve Singer wrote:
> 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.
Thanks!
> Ideally char * members of ExceptionMap would be const, but since many
> versions of python take a non-const value to PyErr
Thank you all for your replies.
So, is there any precise way to discover when sorting is invoked?
Thanks.
Regards.
Fava
Il 11/02/2011 01:17, Robert Haas ha scritto:
On Thu, Feb 10, 2011 at 6:21 PM, Nicolas Barbier
wrote:
2011/2/10 mac_man2...@yahoo.it:
Which operations invoke the sorting
On 02/11/2011 05:05 AM, Tom Lane wrote:
Actually, I was having second thoughts about that while at dinner. What
is the value of separating the bootstrap-an-extension-from-old-objects
operation into two steps? It's certainly not convenient for users, and
I don't see that the intermediate state w
[ Please don't top-post. http://en.wikipedia.org/wiki/Posting_style> ]
2011/2/11 mac_man2...@yahoo.it :
> So, is there any precise way to discover when sorting is invoked?
EXPLAIN shows how a query would be executed; explicit sorts should be
mostly obvious.
http://www.postgresql.org/docs/9.0/sta
I just checked subj. and wondering what does it means and how many spam
we may have on wiki ?
PostgreSQL on OpenSSI enabled Knoppix
From OpenSSI
Jump to: navigation, search
Acai Berry - The Best Protection
For the economy today that are getting down its very important that you can
have such
On Fri, Feb 11, 2011 at 7:14 AM, Oleg Bartunov wrote:
> I just checked subj. and wondering what does it means and how many spam we
> may have on wiki ?
Hmm, that's not our wiki, it's on www.openssi.org.
But I hit the undo link for them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
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
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
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 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
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 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=#
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
>
* 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
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
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
>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 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
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_
=?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 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"?
--
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
* 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 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-
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 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
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
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
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
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
* 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: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
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 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: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
* 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 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
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 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
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 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
* 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'
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
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.
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
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
* 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
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
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:
>>
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
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:
> 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
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
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..
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
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
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
* 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
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
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
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
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
>
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
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
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
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
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 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 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 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
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.
>
>>
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
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
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
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
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
* 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
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
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
> "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 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
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: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
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 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
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 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
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 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
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
> 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
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
* 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
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
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
>
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
* 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
1 - 100 of 209 matches
Mail list logo
