On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote:
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
> ...
> I can easily convert the encode_array_literal to just call this function, but
> not encode_
charles.mcdev...@emc.com wrote:
The GNU people will never be 100% satisfied by anything you do to psql, other
than making it GPL.
Readline is specifically licensed in a way to try to force this (but many
disagree with their ability to force this).
The "GNU people" are perfectly content wit
On Feb 11, 2011 8:20 PM, "Robert Haas" wrote:
>
> On Fri, Feb 11, 2011 at 4:38 PM, Robert Haas
wrote:
> > On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas
> > wrote:
> >> On 11.02.2011 22:11, Robert Haas wrote:
> >>>
> >>> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina
wrote:
>
> I
On Fri, Feb 11, 2011 at 4:38 PM, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas
> wrote:
>> On 11.02.2011 22:11, Robert Haas wrote:
>>>
>>> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
I split this out of the synchronous replication patch for independ
On Fri, Feb 11, 2011 at 6:40 PM, Nick Rudnick wrote:
> I remember well PostgreSQL has an own garbage collection (palloc() etc.;I
> only know it is in utils of the backend, at mmgr), but I didn't find it on
> the TODO list; so
>
> o would you say "hands off the garbage collection" or could you im
marcin mank writes:
> On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote:
>> Hmm. Â That seems like it would require a rather pathological collection
>> of upgrade scripts. Â In particular why would you have a one-step upgrade
>> from 1.1 to 2.0 but no short path from 1.2?
> Say we have 20 versions
On Wed, Feb 9, 2011 at 02:10, 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-ha
On Sat, Feb 12, 2011 at 05:01, Stephen Frost wrote:
> Input arrays are always flattened into one-dimensional arrays.
> That just strikes me as completely broken when it comes to PG Arrays.
Contains operators (<@, &&, @>) ignore multi-dimensions.
Array slice operator ([lo:hi]) always reset the ind
On Feb 11, 2011, at 3:58 PM, Alex Hunsaker wrote:
> You mean... we have been talking past each other this whole time?
Well, since my second post, I think. I was wrong in the first one.
> Olegs case _was_ a utf8 database.
> From his original bug:
>
>>> Hi there, below is the problem, which I don
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote:
> =?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= writes:
>> This has the side effect that you can also have downgrade scripts. I
>> don't know if this is designed or just coincidental, so thought it
>> would be worth mentioning.
>> The worst case is that
On Sat, Feb 12, 2011 at 12:15 AM, wrote:
>> > Ok, but be aware that readline is GPL v3, not GPL v2, and has those
>> > additional
>> requirements.
>>
>> No
>
> What? From the GNU Readline home page: "Readline is free software,
> distributed under the terms of the GNU General Public License, v
"David E. Wheeler" writes:
> On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
>> It can be specified by a "directory" parameter in the control file,
>> and defaults to the same place the control file is. Right now, that's
>> $PREFIX/share/contrib/.
> Frankly, given the likely proliferation of upgra
* charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
> > * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
> > > GnuTLS doesn't qualify.
> >
> > That should be "doesn't currently"..
> >
>
> Doesn't currently? Does that mean you know of a project to get FIPS
> certification f
> -Original Message-
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:14 PM
> To: McDevitt, Charles
> Cc: sfr...@snowman.net; alvhe...@commandprompt.com;
> g...@2ndquadrant.com; mba...@debian.org; t...@sss.pgh.pa.us;
> and...@d
On Feb 10, 2011, at 11:26 PM, Alexey Klyukin wrote:
> On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>>>
>>> Let me try implementing that as an XS interface to plperl_array_to_datum.
>>
>>
>> Are you intending this as a completion of the
On Sat, Feb 12, 2011 at 12:07 AM, wrote:
>> This is just libelous FUD. There's absolutely no reason postgres would
>> have to be GPL'd to satisfy any library license.
>
> Ok, but be aware that readline is GPL v3, not GPL v2, and has those
> additional requirements.
No
--
greg
--
Sent via pg
-Original Message-
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
> Sent: Friday, February 11, 2011 4:03 PM
> On Fri, Feb 11, 2011 at 11:06 PM, wrote:
> > The GNU people will never be 100% satisfied by anything you do to psql,
> > other
> than making it GPL
On Fri, Feb 11, 2011 at 11:06 PM, wrote:
> The GNU people will never be 100% satisfied by anything you do to psql, other
> than making it GPL.
> Readline is specifically licensed in a way to try to force this (but many
> disagree with their ability to force this).
This is just libelous FUD. Th
On Fri, Feb 11, 2011 at 12:11 PM, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
>> I split this out of the synchronous replication patch for independent
>> review. I'm dashing out the door, so I haven't put it on the CF yet or
>> anything, but I just wanted to get it
On Fri, Feb 11, 2011 at 16:42, David E. Wheeler wrote:
> On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
>
>> Yay! 1
>
> Yes, this is all good. But it still seems to me that:
>
> * If your database is neither utf-8 no sql_ascii
You mean... we have been talking past each other this whole time?
On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
> Yay! 1
Yes, this is all good. But it still seems to me that:
* If your database is neither utf-8 no sql_ascii
* And your PL/Perl functions expect arguments that are byte soup
* Once you upgrade to 9.1 they won't be
* So you'll need to encode t
Hi Josh,
at first, thanks for all the interesting info given
Correct, AFAIK.
o extensions of PostgreSQL to support such a kind of usage have to be
expected to be expected to be rejected from integration to the code base
core -- i.e., if they are done, students have to be told «you can't
expec
I wrote:
> Patch attached.
This time with src/backend/utils/misc/postgresql.conf.sample fixed.
-Kevin
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 5188,5202 dynamic_library_path =
'C:\tools\postgresql;H:\my_project\lib;$libdir'
> * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
> > Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
> compliance is essential to many Federal users.
>
> Essential? That's a bit much. Yes, it shows up on a FISMA review as an
> open action item, but it's a r
Stephen Frost wrote:
> Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd be happy with "max_pred_locks_per_transaction" which gets the
>> worst case down without being too obviously at variance with
>> "max_locks_per_transaction".
>
> Sounds good to me. The header length for show all would drop to
>
On Fri, Feb 11, 2011 at 5:22 PM, Martijn van Oosterhout
wrote:
> On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote:
>> Note that the past discussion was on the difficulty of matching the
>> existing OpenSSL API using GnuTLS, which is apparently difficult to do.
>> I wasn't trying to sugge
2011/2/11 Kevin Grittner :
> "mac_man2...@yahoo.it" wrote:
>
>> I need to know, from an algorithmic point of view, in which cases
>> sorting is invoked.
[..]
> Are your really looking to categorize the types of queries where
> sorting is *invoked*, or the ones where it is *considered*? Or
> pe
On Fri, Feb 11, 2011 at 10:11:45AM -0800, Jeff Davis wrote:
> The cost, of course, is that not all operations are well-defined for
> empty ranges. I think those are mostly operators like those mentioned in
> the other thread: ">>" (strictly right of), "<<" (strictly left of), and
> "-|-" (adjacent)
On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote:
> Note that the past discussion was on the difficulty of matching the
> existing OpenSSL API using GnuTLS, which is apparently difficult to do.
> I wasn't trying to suggest there were issues specificially with GnuTLS's
> code qualit
FWIW, a very informal survey of probabilists didn't yield any reason
for trying to put an order on the empty set ( unless the metric was
cardinality or other equivalence relation ).
I think the problem here is that the idea of union and intersection
forming a ring over sets is being conflated with
On Thu, Feb 10, 2011 at 8:13 AM, Itagaki Takahiro
wrote:
> On Thu, Feb 10, 2011 at 19:37, Christoph Berg wrote:
>> Currently, tab-completing :variable names in psql does not work at the
>> beginning of the line. Fix this by moving the code block before the
>> "empty buffer" case.
>
> Seems reason
On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas
wrote:
> On 11.02.2011 22:11, Robert Haas wrote:
>>
>> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
>>>
>>> I split this out of the synchronous replication patch for independent
>>> review. I'm dashing out the door, so I haven't put it
* Robert Haas (robertmh...@gmail.com) wrote:
> > Teodor sent it to the list Dec 28, see
> > http://archives.postgresql.org/message-id/4D1A1677.80300%40sigaev.ru
[...]
> That having been said, this looks like a fairly mechanical change to a
> contrib module that you and Teodor wrote. So I'd say if
On 11.02.2011 22:11, Robert Haas wrote:
On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be ar
Jeff Davis wrote:
>> Perhaps it was a mistake to get so concrete rather than
>> conceptual -- basically, it seems like it could be a useful
>> concept for any planned or scheduled range with an indeterminate
>> end point, which you want to "reserve" up front and record in
>> progress until compl
On Fri, Feb 11, 2011 at 12:25 PM, Stephen Frost wrote:
> * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
>> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
>> compliance is essential to many Federal users.
>
> Essential? That's a bit much. Yes, it shows up
On Fri, Feb 11, 2011 at 11:07, David E. Wheeler wrote:
> I don't understand where the bug is. If a string is encoded in utf-8 Perl
> will not treat it as such unless the utf-8 flag is set.
Ok so I think we agreed this is right:
$ perl -E 'use URI::Escape; my $str = uri_unescape("%C3%A9"); say
s
Tom Lane writes:
> I don't see what that does for you. This is still all being examined by
> a particular major release of PG, so what will it do with a require that
> specifies some other major release? Nothing useful. And there's a very
> significant downside, which is that this takes us righ
Tom Lane writes:
> Anything that got kicked out to pgfoundry would presumably start acting
> that way. Anything that's part of core git is going to stay on the same
> release cycle as the core, thank you very much. Release engineering is
> a big enough headache around here already.
Yeah, I shou
Tom Lane writes:
>> The worst case is that if you are upgrading from 1.2 to 2.0 the path
>> is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 ->
>> 2.0. This could potentially result in data loss, if the downgrade
>> drops some columns or something like that.
>
> Hmm. That seems
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think it'd likely be sufficient to bump them only once per release
>> cycle, ie, there's no need to distinguish versions that never appeared
>> in the wild. But if we forgot and created 1.1 early in the 9.2 release
>> cycle and 1.2 late in the cyc
"mac_man2...@yahoo.it" wrote:
> I need to know, from an algorithmic point of view, in which cases
> sorting is invoked.
Well, I think the only accurate answer to that is "when the
estimated cost of a plan using a sort is lower than the estimated
cost of any alternatives". There are cases wher
Looks like the function get_actual_variable_range() was written with the
knowledge that virtual/hypothetical indexes may exist, but the assumption
seems wrong.
One one hand get_actual_variable_range() expects that virtual indexes do not
have an OID assigned, on the other hand explain_get_index_na
On Fri, 2011-02-11 at 15:14 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis wrote:
> > Well, there is a certain amount of localized clarity, I will agree with
> > that. The complexity comes when you accidentally rely on some
> > transformation which seems logically sound, b
Tom Lane writes:
> I think it'd likely be sufficient to bump them only once per release
> cycle, ie, there's no need to distinguish versions that never appeared
> in the wild. But if we forgot and created 1.1 early in the 9.2 release
> cycle and 1.2 late in the cycle, there's no great harm done e
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.s
On Fri, 2011-02-11 at 14:19 -0600, Kevin Grittner wrote:
> Well, in the receipt number example there are multiple ranges in use
> for each year, and ranges for multiple years. If we get to the idea
> of a multi-ranges, this would be very handy for certain types of
> reports -- especially for audit
Dimitri Fontaine writes:
> Tom Lane writes:
>> I don't see that this proposal changes anything about that. It's still
>> the case that the underlying .so is tied to a major PG version. What
>> you'll ship is a control file and assorted .sql files that represent the
>> user APIs you are interest
Tom Lane writes:
> Dimitri Fontaine writes:
>> Will we have to provide different upgrade scripts for different past
>> major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would
>> be better names. hstore at least is an example that would need this
>> treatment I guess.
>
> I don't f
Nicolas, thanks.
Unfortunately I don't think I can get precise infos from that link. That
"explains" how the EXPLAIN works, while I need to know, from an
algorithmic point of view, in which cases sorting is invoked.
Actually, maybe I can spend some time in trying to perform samples
queries and
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We have code that exists in both psql and the backend (cf src/port/)
> so I'm not sure this really will satisfy the more rabid GPL partisans.
We're talking Debian, who, yes, are a bit pickier when it comes to
trying to actually follow the licneses the
Aidan Van Dyk writes:
> So, I like that the attempt is to support multiple versions. But
> unless you can manage the files (both shared libraries, and any
> scripts to create/update SQL objects) for different version
> independently, I can't see the "multiple versions at once" capabilites
> that
Tom Lane writes:
> I don't see that this proposal changes anything about that. It's still
> the case that the underlying .so is tied to a major PG version. What
> you'll ship is a control file and assorted .sql files that represent the
> user APIs you are interested in supporting on that major P
Robert Haas writes:
> On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote:
>> We have code that exists in both psql and the backend (cf src/port/)
>> so I'm not sure this really will satisfy the more rabid GPL partisans.
>> And this whole discussion is about satisfying the most rabid of them,
>> reme
* charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
> compliance is essential to many Federal users.
Essential? That's a bit much. Yes, it shows up on a FISMA review as an
open action item, but it's a risk that
If psql uses libreadline and libgnutls, does that mean psql will be distributed
under the GPL in the future? Or Dual-licensed?
If I read the readline license right, applications that link to it must be GPL.
That's why we (EMC/Greenplum) switch to libedit, even though readline is
nicer... We di
Robert Haas writes:
> On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane wrote:
>> I should also make clear that I intend to start out all the contrib
>> modules at version 1.0.
> What happens if their contents change several times during a major
> release cycle?
I think it'd likely be sufficient to bum
On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Why do we have to involve the whole of PostgreSQL? Since the only piece
>> that links to libreadline is psql, perhaps we could fix this by having
>> only psql optionally use GnuTLS.
>
> We have code that exists in both
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> 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 thinking about using eit
Jeff Davis wrote:
> Trying to incorporate a "start value" is adding extra information
> in there, and it's not really a part of the same algebra. It
> sounds more like a contiguous sequence with a "start value" and a
> "current value" to me.
Well, in the receipt number example there are multip
Tom Lane writes:
> 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]
Agreed.
> If VERSION is not specified, v is taken from default_version in the
> control file, or fail i
Dimitri Fontaine writes:
> Tom Lane writes:
>> 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 thinking about using either "old" or "unpackaged".
>> Thoughts?
> Will we have
On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis wrote:
> Well, there is a certain amount of localized clarity, I will agree with
> that. The complexity comes when you accidentally rely on some
> transformation which seems logically sound, but could result in a
> transient empty range, which then throw
On Fri, 2011-02-11 at 14:14 -0500, Robert Haas wrote:
> > It's really that it has nice mathematical properties coming from set
> > theory. Take the distributive law:
> >
> > A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C)
>
> But the basic range type isn't even closed under UNION.
An
On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
> I split this out of the synchronous replication patch for independent
> review. I'm dashing out the door, so I haven't put it on the CF yet or
> anything, but I just wanted to get it out there...I'll be around in
> Not Too Long to finish any
Alvaro Herrera writes:
> Why do we have to involve the whole of PostgreSQL? Since the only piece
> that links to libreadline is psql, perhaps we could fix this by having
> only psql optionally use GnuTLS.
We have code that exists in both psql and the backend (cf src/port/)
so I'm not sure this r
Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
compliance is essential to many Federal users.
GnuTLS doesn't qualify.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
"David E. Wheeler" writes:
> On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote:
>> It would be good to avoid regexp and globing pattern characters, I would
>> say.
>>
>> There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I
>> wonder if : would be good? "foo:1.0:1.1.sql". A
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
> Note that the past discussion was on the difficulty of matching the
> existing OpenSSL API using GnuTLS, which is apparently difficult to
> do.
Oh, yes, that's more a reflection on the crappy API that OpenSSL has
than on anything else, in my vi
On Fri, Feb 11, 2011 at 7:49 PM, Tom Lane wrote:
> If you were expecting this proposal to make things easier as far as
> dealing with multiple major releases, sorry, our ambitions don't extend
> that far yet.
Sorry, I might have been confusing here... I'm not talking about *PG*
major releases.
On Fri, 2011-02-11 at 14:59 -0500, charles.mcdev...@emc.com wrote:
> If psql uses libreadline and libgnutls, does that mean psql will be
> distributed under the GPL in the future? Or Dual-licensed?
libgnutls is libgpl, not GPL, so this is not a problem.
JD
--
PostgreSQL.org Major Contributor
On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis wrote:
> > Similarly, "intersection" of ranges is somewhat analogous to
> > multiplication of numbers.
>
> I had a feeling that we might be going in this direction. It strikes
> me that this case
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I will remove parser changes from the patch; it will add only a few array
> functions. Then, please let me know functions you don't want to include
> in the core, if any. I'll remove them at the same time.
Seems like this should be 'waiting
On Feb 11, 2011, at 10:28 AM, Josh Berkus wrote:
> So, if we allow empty ranges of this kind, I would want a GUC for
> "allow_empty_ranges".
GUC you, josh. ;-P
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Fri, Feb 11, 2011 at 11:49 AM, Alvaro Herrera
wrote:
> Why do we have to involve the whole of PostgreSQL? Since the only piece
> that links to libreadline is psql, perhaps we could fix this by having
> only psql optionally use GnuTLS. (I don't know if you can make an
> OpenSSL server talk to
On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote:
> It would be good to avoid regexp and globing pattern characters, I would
> say.
>
> There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I
> wonder if : would be good? "foo:1.0:1.1.sql". A very quick test seems
> to show t
Tom Lane writes:
> In principle we are leaving it to the extension author to choose that.
Most extensions already have a version number. ip4r is 1.05, prefix is
1.1.0, dbi-link is 2.0.0, temporal is 20091213, tablelog is 0.4.4, etc.
All those extensions will need a newer 'extension' release to s
Excerpts from Greg Smith's message of vie feb 11 14:51:17 -0300 2011:
> So where are we at?
>
> -GNU libreadine is certainly never going to add an OpenSSL exemption
> -If the OpenSSL project was going to switch to a reasonable license,
> they'd have done it years ago
> -There are many known and
Aidan Van Dyk writes:
> On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane wrote:
>> No, you ship *one* package that supports both 1.1 and 2.0.
> Hm... As an example of a project that generally has pretty good
> software release practices, I'm glat that the PostgreSQL project
> doesn't operate this way.
On Fri, Feb 11, 2011 at 2:17 PM, Noah Misch wrote:
> Good to know. I can envision that perspective, and I share it when the
> savings
> is rather more substantial, say >10% of the patch or >100 lines. Below that
> threshold, the energy I expend grasping two interface changes in one patch
> seri
On Fri, 2011-02-11 at 13:08 -0600, Kevin Grittner wrote:
> It makes more sense in the context of a range of some type with a
> clearly defined granularity. Our accounting system, for example,
> can assign a new range of receipt IDs for each calendar year. If
> you want a variable to represent the
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane wrote:
>> This gives my first problem. I can't package afoo-2.x seperately from
>> afoo-1.x, because they both want to write the afoo control file.
>
> No, you ship *one* package that supports both 1.1 and 2.0.
Hm... As an example of a project that gen
On Fri, Feb 11, 2011 at 2:09 PM, Greg Smith wrote:
> Note that the past discussion was on the difficulty of matching the existing
> OpenSSL API using GnuTLS, which is apparently difficult to do.
I believe that the OpenSSL API is "make some function calls, and if it
works, then you're using it rig
On Fri, Feb 11, 2011 at 6:30 PM, Tom Lane wrote:
> No --- in the current vision, a control file may describe a whole
> collection of versions of the same extension, and the parameter in
> question is selecting the default or preferred version to install.
> I'm not wedded to "default_version", but
Aidan Van Dyk writes:
> And I now release and updated version 1.1 which fixes a problem. No problem:
>afoo control file:
> - default_version = 1.1
> - encoding utf8
>afoo-1.1.sql installation
>afoo-upgrade-1.0-1.1.sql upgrade script
>any required shared libraries for afo
On Feb 11, 2011, at 10:58 AM, Aidan Van Dyk wrote:
> I release exetension "afoo", initial as version 1.0. From my
> understanding, it's going to contain:
>afoo control file, named something particular)
> - default_version = 1.0
> - encoding utf8
>foo-1.0.sql installstion script
On Fri, Feb 11, 2011 at 20:09, Greg Smith wrote:
> Stephen Frost 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. :/
>
>
> Note that the past discuss
On Fri, Feb 11, 2011 at 01:55:45PM -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote:
> > Even supposing we push off all scan-only cases to another patch, it would be
> > good to have the tablecmds.c-internal representation of that in mind. ?No
> > sense
> > in simplif
Robert Haas writes:
> On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane wrote:
>> I'm not very happy with that at all, either as to the concept or the
>> specific version-alias names. I don't think that CREATE and ALTER
>> really need different default version targets. And those choices of
>> names car
"Kevin Grittner" wrote:
> Basically, with a type having well-defined granularity, a [) range
> could usefully represent, "start to last used", and start out
> empty.
I guess that would actually be "start to next available"
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= writes:
> This has the side effect that you can also have downgrade scripts. I
> don't know if this is designed or just coincidental, so thought it
> would be worth mentioning.
Yeah, that's intentional and IMO worth supporting.
We do have to be sure that t
On Fri, Feb 11, 2011 at 2:06 PM, Jeff Davis wrote:
> On Fri, 2011-02-11 at 10:28 -0800, Josh Berkus wrote:
>> I guess I'm having trouble tying the concept of empty ranges to any
>> reality external to the database.
>
> That's true, but in the same sense as zero has no meaning outside of the
> data
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
> No --- in the current vision, a control file may describe a whole
> collection of versions of the same extension, and the parameter in
> question is selecting the default or preferred version to install.
> I'm not wedded to "default_version", but I t
Stephen Frost 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. :/
Note that the past discussion was on the difficulty of matching the
existing OpenSS
Robert Haas wrote:
>> I think that range '[15:15:00,15:15:00)' should be valid as a
>> zero-length range between, for example, '[15:00:00,15:15:00)' and
>> '[15:15:00,15:30:00)'.
>
> How would that actually work? I kind of agree with Josh: I'd be
> inclined to make the type input function boot
On Fri, 2011-02-11 at 10:28 -0800, Josh Berkus wrote:
> I guess I'm having trouble tying the concept of empty ranges to any
> reality external to the database.
That's true, but in the same sense as zero has no meaning outside of the
database.
It's really that it has nice mathematical properties c
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.s
On Fri, Feb 11, 2011 at 1:50 PM, Kevin Grittner
wrote:
> 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
On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote:
> Even supposing we push off all scan-only cases to another patch, it would be
> good to have the tablecmds.c-internal representation of that in mind. No
> sense
> in simplifying a 12-line change to an 8-line change, only to redo it next
> patc
On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis wrote:
> Similarly, "intersection" of ranges is somewhat analogous to
> multiplication of numbers.
I had a feeling that we might be going in this direction. It strikes
me that this case is a bit like division by zero. It's kind of a
nuisance that divi
1 - 100 of 209 matches
Mail list logo
