On May 18, 2011, at 1:47 PM, Dimitri Fontaine wrote:
> Well, I'm not sure I buy into that idea, I need to think about it some
> more. The thing with debian for example is that the package building
> needs to be all automatic, and determistic — you're not granted to have
> the next version build a
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
> I don't see why it couldn't, at least for a fair number of
> extensions.. It does require the ability to differentiate between
> patch releases and feature releases, though, which I believe is
> currently missing in pgxn (correct me if i'm wron
On May 18, 2011, at 2:58 PM, Magnus Hagander wrote:
> Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
> time? I somehow got the idea that old versions were removed when I
> uploaded a new one, but I happy to be wrong :-)
The distribution has only one version, of course, but
On May 18, 2011, at 3:08 PM, Magnus Hagander wrote:
>> The distribution has only one version, of course, but perl extensions in
>> 9.1, you can include multiple versions of an extension in one distribution.
>
> Won't that break if different (major) versions have different dependencies?
I don't
On May 18, 2011, at 3:22 PM, Magnus Hagander wrote:
> If I include both version 1 and version 2 of an extension in one. And
> version 2 has more dependencies than version 1 (or the other way
> around). Then those dependencies will be required for version 1 as
> well...
Yes. But if they're that de
On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> Yes. But if they're that decoupled, then they ought to be in separate
>> distributions.
>
> I somehow fail to picture how you map distributions with debian
> packages. T
On May 24, 2011, at 9:12 AM, Tom Lane wrote:
> An alternative rule we could use in place of #2 is just "smash domains
> to base types always, when they're matched to ANYELEMENT". That would
> be simpler and more in keeping with #1, but it might change the behavior
> in cases where the historical
On May 24, 2011, at 10:11 AM, Tom Lane wrote:
> regression=# select negate(42::pos);
> ERROR: return type mismatch in function declared to return pos
> DETAIL: Actual return type is integer.
> CONTEXT: SQL function "negate" during inlining
>
> If we smashed to base type then this issue would g
On May 24, 2011, at 11:30 AM, Tom Lane wrote:
> Well, if they actually were first-class types, they probably wouldn't
> be born with an implicit cast to some other type to handle 99% of
> operations on them ;-). I think the hard part here is having that cake
> and eating it too, ie, supporting do
On May 27, 2011, at 1:43 PM, Alvaro Herrera wrote:
> Right now we rely on the tzdata files on disk for things like
> pg_timezone_names and other accesses of TZ data; so the files are the
> authoritative source of TZ info. So we need to ensure that whenever the
> files are updated, the catalogs ar
On May 27, 2011, at 2:35 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> I like it, but what do you do when a TZ has been renamed or has ceased
>> to exist.
>
> As far as that goes, I think "nothing" is a sufficient answer. There's
>
On Jun 3, 2011, at 8:22 AM, Robert Haas wrote:
> Well, as Bill Clinton once said, "it depends on what the meaning of
> the word 'is' is". I think of array types in PostgreSQL as meaning
> "the types whose monikers end in a pair of square brackets".
Man, range types are going to fuck with your br
On Jun 6, 2011, at 1:14 PM, Tom Lane wrote:
> The most workable alternative that I can see is to lobotomize citext so
> that it always does lower-casing according to the database's "default"
> collation, which would allow us to pretend that its notion of equality
> is not collation-sensitive after
On Jun 6, 2011, at 4:35 PM, Tom Lane wrote:
>> That sounds like a good idea.
>
> BTW, it struck me shortly after sending this that we'd already discussed
> the idea of a flag in pg_proc showing whether a function pays attention
> to collation. We could of course use that for this purpose.
Seems
I was reading the partitioning docs when I spotted this. I think it means to
highlight the advantages of DROP TABLE over DELETE rather than ALTER TABLE.
Best,
David
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 4c9fc5d..0cdb800 100644
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src
On Jun 14, 2011, at 8:03 AM, Tom Lane wrote:
>> - ALTER TABLE is far faster than a bulk operation.
>> + ALTER TABLE (to split out a sub-table from the partitioned
>> + table) and DROP TABLE (to remove a partition altogether)
>> are
>> + both far faster than a bulk operation.
>
On Jun 19, 2011, at 4:56 PM, Florian Pflug wrote:
> Hm, it seems we either all have different idea about how such
> a pattern type would be be defined, or have grown so accustomed to
> pg's type system that we've forgotten how powerful it really
> is ;-) (For me, the latter is surely true...).
>
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-30 00:00:00
2011-08-30 00:00:00
2011-09-30 00:00:00
201
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
> That's just how intervals that represent varying periods of time work. You
> would need to write your own. But a series of end-of-month dates is pretty
> easy:
> select generate_series('2011-06-01'::timestamp , '2012-04-01'::timestamp, '1
>
On Jun 27, 2011, at 11:03 AM, Kevin Grittner wrote:
> It is precisely to support such fancy things that some products
> support a more abstract date type which allows 31 days in any month,
> and then normalizes to real dates as needed. The PostgreSQL
> developer community has generally not been r
On Jun 27, 2011, at 11:36 AM, Steve Crawford wrote:
> The query is marginally trickier. But the better calendaring apps give a
> variety of options when selecting "repeat": A user who selects June 30, 2011
> and wants a monthly repeat might want:
>
> 30th of every month - skip months without a
On Jun 27, 2011, at 12:36 PM, Christopher Browne wrote:
> I wrote something on this on pgsql-general about 5 years ago that
> still seems pretty relevant.
>
> http://archives.postgresql.org/pgsql-general/2006-02/msg00159.php
iwantsandy.com (now defunct) originally had a solution like this. Howev
On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote:
> Do we think that this is a good way forward? The only thing I can think
> of that's undesirable is that it's not normal to be required to cast the
> result of a function, and might be slightly difficult to explain in the
> documentation in a straigh
On Jun 28, 2011, at 8:02 PM, Jeff Davis wrote:
> I think David Wheeler was trying to make a similar point, but I'm still
> not convinced.
>
> It's not a pair, because it can be made up of 0, 1, or 2 scalar values
> (unless you count infinity as one of those values, in which case 0 or
> 2). And wi
On Jun 29, 2011, at 8:41 AM, Jeff Davis wrote:
> We could make it a pseudo-type and make the IO functions generate
> exceptions. That should prevent most mistakes and effectively hide it
> from the user (sure, they could probably use it somewhere if they really
> want to, but I wouldn't be worried
On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
> Because there might be more than one range type for a
> base type. Say there are two range types over text, one
> with collation 'de_DE' and one with collation 'en_US'.
> What would the type of
> range('foo', 'f')
> be?
The one that corres
On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote:
> Right. In that respect, it's more like a record type: many possible
> record types exist, but you only define the ones you want.
Well, okay. How is this same problem handled for RECORD types, then?
>> By default, no range types would exists I beli
On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
> Then how do you get a text range that doesn't correspond to the
> LC_COLLATE setting?
You cast it.
> Does that mean you couldn't dump/reload from a
> system with one collation and get the same values in a system with a
> different collation? That
On Jun 30, 2011, at 12:09 PM, Alvaro Herrera wrote:
> Robert Hass (whose name I misspelled in the commit message above) just
> mentioned to me (in an answer to my apologizing about it) that he didn't
> think that mentioning sponsors for patch development was a good idea.
>
> I don't think we have
Hackers,
I'm building a new server using 9.1beta2. My build script includes these two
line:
make world -j3 || exit $?
make install-world || exit $?
Much to my annoyance, `make world` seems to succeed, but the script exits with
no error message. So the second line never executes. I comm
On Jan 26, 2011, at 7:48 AM, Richard Broersma wrote:
> On Wed, Jan 26, 2011 at 7:38 AM, David Fetter wrote:
>
>> I'm thinking that we should consider *very* carefully before we
>> introduce payments into what had been an all-volunteer effort. You
>> may get people to do things they might not o
On Jan 26, 2011, at 9:40 AM, Richard Broersma wrote:
> On Wed, Jan 26, 2011 at 9:31 AM, David E. Wheeler
> wrote:
>> Part of GCOC's success has been in allowing a class of people to
>> participate who otherwise would have had to get summer jobs flipping
>> bu
On Jan 27, 2011, at 9:17 AM, Tom Lane wrote:
> The Postgres core team will be wrapping update releases for all
> supported back branches this evening. These updates are prompted by
> a minor security issue (reported by Apple, curiously enough) as well
> as desire to push out some significant bug
On Jan 28, 2011, at 9:48 AM, Jeff Davis wrote:
> On Fri, 2011-01-28 at 09:17 -0800, David Fetter wrote:
>> For consistency, and in order not to continue our atrocious naming
>> tradition, I'd like to propose that the above be named timestamprange
>> (tsrange for short) and timestamptzrange (tstzra
On Jan 29, 2011, at 10:57 AM, Jeff Davis wrote:
> On Fri, 2011-01-28 at 10:41 -0800, David E. Wheeler wrote:
>> +1 in principal. I think we should try to avoid the user of the term
>> "period" if possible, and I see definite benefits to a simple model of
>> $typen
On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
> Well, you write 3 scripts.
>
> Let's consider an example, the lo contrib, with its 3 objects:
>
> CREATE DOMAIN lo AS pg_catalog.oid;
> CREATE OR REPLACE FUNCTION lo_oid(lo) …
> CREATE OR REPLACE FUNCTION lo_manage() …
>
> Now, the upgrad
On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
> Well, fair enough I suppose. Or it would be if you gave me an
> alternative that provides a simpler way to support those 3 upgrades.
I did: a naming convention with upgrade scripts that have the version number in
them. You rejected it.
> Of
On Feb 2, 2011, at 9:19 AM, Dimitri Fontaine wrote:
> I see there no solution to your reaction here. Please take the time to
> tell us more about what exactly it is that you hated, and how to make it
> lovely. We won't make any progress with your current commenting style.
Here is your example o
On Feb 2, 2011, at 10:04 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> They are identical except for the extra line in the second one. If I
>> had, say 15 different versions of an extension, then I'd have 15
>> upgrade scripts. That's fine
On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
> My concern with this approach (upgrade is forced through all
> intermetiary versions) is that the shared libray now for version 15
> *has* to have all the "intermediary" compatibility for *all* versions
> in it. So it has to have functions with
On Feb 2, 2011, at 10:22 AM, Dimitri Fontaine wrote:
> Either one line in the Makefile or a new file with the \i equivalent
> lines, that would maybe look like:
>
> SELECT pg_execute_sql_file('upgrade.v14.sql');
> SELECT pg_execute_sql_file('upgrade.v15.sql');
>
> So well… I don't see how you'
On Feb 3, 2011, at 4:23 AM, Alexey Klyukin wrote:
>> - Making the conversion lazy would be a big help.
>
> Converting it to string is already lazy, and, per the argumens above, I don't
> see a real benefit of lazy conversion to the perl reference (as comparing to
> the hurdles of implementing tha
On Feb 3, 2011, at 9:38 AM, Tom Lane wrote:
> Given that pg_upgrade is now considered a supported piece of the system,
> ISTM that most real-world upgrade scenarios will be accomplished with
> pg_upgrade relying on provision (3). It looks to me like we're talking
> about adding a large amount of
On Feb 3, 2011, at 9:54 AM, Robert Haas wrote:
> I think you can pretty much take it to the bank that there will be
> demand. This is an important, real-world problem.
>
> That having been said, I'm not 100% convinced that the main extensions
> patch is ready for prime-time, and I'm even less co
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
> Well, pg_upgrade is designed to work within a major-version series, eg
> you could do a 9.1-to-9.1 upgrade if you needed to install a newer
> version of an extension. Admittedly, this is swinging a rather larger
> hammer than "apply an upgrade script
On Feb 3, 2011, at 11:02 AM, Tom Lane wrote:
>> That's putting it mildly. It's more like sending a rocket into outer
>> space to tweak the orbit of a comet so that it crashes into your
>> barbecue grill to light a fire so you can roast marshmallows.
LOL.
> No, it's more like using a sledgehamme
On Feb 3, 2011, at 11:35 AM, Josh Berkus wrote:
> (D) Requires a series of ordered upgrade scripts in sortable version
> numbering, each of which gets applied in order between the two versions.
> This initially seems like the most attractive option -- and is the one
> used by dozens of popular ope
On Feb 4, 2011, at 7:48 AM, Robert Haas wrote:
> I'd like to answer this question, but I have not had enough time to
> read through this patch in detail, because there are 97 patches in
> this CommitFest. The point I'm trying to make, however, is
> procedural. We shouldn't commit anything at the
On Feb 4, 2011, at 8:54 AM, Robert Haas wrote:
> Yeah, I understand. I believe Tom said he was going to look at the
> basic functionality with an eye toward commit, and I hope to look at
> it as well, either before or after it gets committed. Time
> permitting, I'd then like to look at this, but
On Feb 6, 2011, at 10:23 AM, Tom Lane wrote:
> I've not attempted to implement this idea, but offhand it looks like
> it would take a day or two's work, which seems well worthwhile to
> expend now in the hope of getting this feature right the first tim
Seems worthwhile, and a much better approach
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
> Yeah, this is another approach that one could take instead of having
> per-row flags. I'm not sure that it's better, much less so much better
> that we should force extensions to do it that way and not the other.
> But it's definitely another argument
On Feb 7, 2011, at 9:20 AM, Dimitri Fontaine wrote:
> Also, I didn't bite this bullet, but maybe we should provide core PLs as
> extension. Then CREATE LANGUAGE would maybe get deprecated and only
> valid when used in an extension's script — or the next patch (UPGRADE)
> will take care of create
On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
> Interesting point. It's all right at the moment because I tweaked
> pg_dump_sort.c so that procedural languages are dumped before modules.
> But maybe we should convert the PLs to modules.
s/modules/extensions/?
David
--
Sent via pgsql-hackers ma
On Feb 7, 2011, at 10:23 AM, Tom Lane wrote:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something
On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:
> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
> UPGRADE is pretty much a must-have for a useful feature regardless of
> this issue. I had previously thought that we might be able to limp
> along with half a feature for one re
On Feb 8, 2011, at 10:03 AM, Robert Haas wrote:
> No, this is not doable, or at least not in a way that provides any
> benefit over just dropping and reinstalling. The problem is that it
> is going to fall down all over the place if other objects are
> depending on objects provided by the extensi
On Feb 8, 2011, at 10:24 AM, Tom Lane wrote:
>> Ah, right, of course. I don't suppose CREATE OR REPLACE would work, either,
>> in some cases at least?
>
> But figuring out just what commands to issue is pretty nearly AI-complete.
> The whole point of ALTER EXTENSION UPGRADE is to have a human do
On Feb 9, 2011, at 9:20 AM, Robert Haas wrote:
> There are certainly some patches in this CommitFest that need more
> attention than that, and that probably need the attention of a senior
> community member. Jeff's range types patch and Alvaro's key lock
> patch are two of those. And I would be
On Feb 8, 2011, at 6:48 PM, Tom Lane wrote:
> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
> assuming that there can be only one owning extension for an object.
> Furthermore, it's not really intended for *removal* of an object from an
> extension (a concept that doesn't ev
On Feb 9, 2011, at 10:29 AM, Robert Haas wrote:
>> Frankly, I think you should surrender some of those 14 and cajole some other
>> folks to take on more.
>
> Happily... only trouble is, I suck at cajoling. Even my begging is
> distinctly sub-par.
>
> Plase?
Try this:
“Listen up, bit
On Feb 9, 2011, at 10:56 AM, Robert Haas wrote:
>> “Listen up, bitches! I'm tired of Tom and me having to do all the work. All
>> of you who submitted patches need to review some other patches! If you
>> haven't submitted a review for someone else's patch by commitfest end, your
>> patches will
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 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
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: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
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 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 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 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.
>
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
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
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
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 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 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
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 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
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 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 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 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 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
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 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
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 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
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 Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
> I did think of another idea besides forbidding dash in extension names:
> what if we use double dash as the name/version separator, ie the naming
> conventions are like
> extension--version.control
> extension--version.sql
> extensio
On Feb 12, 2011, at 3:12 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
>>> I did think of another idea besides forbidding dash in extension names:
>>> what if we use double dash as the name/version separa
On Feb 12, 2011, at 3:37 PM, Tom Lane wrote:
>> How likely is *that*?
>
> Not very, but the rules are getting a bit complicated ...
Doesn't seem complicated to me:
1. Use -- to separate extension name, old version, new version
2. Don't use - at the beginning or end of name or version number
3.
On Feb 13, 2011, at 11:34 AM, Tom Lane wrote:
> OK, so with that, attached is an example of the complete conversion diff
> for a contrib module (hstore in particular). Although "git status"
> reports hstore--1.0.sql as being a rename of hstore.sql.in, "git diff"
> doesn't seem to be exceedingly b
On Feb 13, 2011, at 4:46 PM, Tom Lane wrote:
>> I sure would like it if the install script with no version in it
>> corresponded to the latest version. Otherwise, one must rename the file
>> every time one does a release. And as you're noting, you lose Git history
>> that way.
>
> (1) git does
On Feb 13, 2011, at 4:59 PM, Tom Lane wrote:
> I think after a couple of releases you'd be shipping something like
>
> foo--1.0.sql
> foo--1.1.sql
> foo--1.0--1.1.sql
> foo--2.0.sql
> foo--1.1--2.0.sql
>
> and it'll soon get to be a mess if your SCM doesn't clearly
On Feb 14, 2011, at 8:54 AM, Tom Lane wrote:
>> I'm not convinced. There was nothing in that discussion why any
>> particular character would have to be allowed in a version number.
>
> Well, there's already a counterexample in the current contrib stuff:
> uuid-ossp. We could rename that to uui
On Feb 14, 2011, at 9:14 AM, Tom Lane wrote:
> Commas do not seem like an improvement to me at all --- they are widely
> used as list separators.
Fair enough.
> I guess the real question is what's Peter's concrete objection to the
> double-dash method?
Hey, I know, a double-dash between the ext
Hackers,
Is it possible to modify the default tsearch parser so that / doesn't get lexed
as a "file" token? That is, instead of this:
try=# select * from ts_debug('simple'::regconfig, 'w/d');
alias │description│ token │ dictionaries │ dictionary │ lexemes
───┼───┼──
On Feb 14, 2011, at 5:03 PM, Tom Lane wrote:
>> Are we deparsing the names of the SQL files to infer the set of
>> version numbers we have to worry about? It seems to me that if
>> there's a list of known version numbers somewhere, we can use dash as
>> the separator without any special restricto
On Feb 14, 2011, at 5:42 PM, Tom Lane wrote:
>> Remember also that not all modules out there on the net will have been
>> updated either, so we must be able to discuss "extension-izing a
>> module". (??)
>
> Right. So it seems like we ought to stick with more or less the
> existing terminology:
On Feb 14, 2011, at 3:57 PM, Tom Lane wrote:
> There is zero, none, nada, provision for modifying the behavior of the
> default parser, other than by changing its compiled-in state transition
> tables.
>
> It doesn't help any that said tables are baroquely designed and utterly
> undocumented.
>
On Feb 14, 2011, at 8:18 PM, Tom Lane wrote:
>>
>> Yes, but the truth is that the extension name, at least, is known from the
>> control file.
>
> Yeah, I think it's true in the current code base that we always know the
> extension name we are interested in. However, that's no protection if
>
501 - 600 of 1570 matches
Mail list logo
