On Jul 12, 2011, at 1:40 PM, k...@rice.edu wrote:
> That is why I think having the UUID generators be a contrib module
> is the correct place for them to be, but the UUID type is better as
> a core function.
I'm okay with this, though given the fact that ftp.ossp.org has been down for
*months*,
On Jul 12, 2011, at 12:19 PM, Alex Hunsaker wrote:
> All Arrays in 9.0 and lower are strings, regardless of if they are
> comprised of composite types. Its not so much a bug as a limitation.
> Alexey Klyukin fixed this for 9.1 :-)
Oh?
dump
--
Hackers,
Given this script:
BEGIN;
CREATE TYPE foo AS ( this int, that int );
CREATE OR REPLACE FUNCTION dump(foo[]) returns text language plperlu AS $$
use Data::Dumper; Dumper shift;
$$;
CREATE OR REPLACE FUNCTION dump(foo) returns text language plperlu AS $$
On Jul 7, 2011, at 12:30 AM, Pavel Stehule wrote:
> thank you very much for review.
I thank you, too, Hanada-san. I was assigned to review this patch, but you beat
me to it. So now I'll do the follow-up review.
> I cleaned patch and merged your documentation patch
>
> I hope, this is all - a l
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 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
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 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 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 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 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 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 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 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 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 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
>
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 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...).
>
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.
>
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 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
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 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 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 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 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 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 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 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 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: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 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 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 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 1:23 PM, Tom Lane wrote:
>> I think building tools so that PGXN distributions are automatically
>> harvested and turned into StackBuilder/RPM/.deb binaries would be the place
>> to start on that.
>
> Hmmm ... I think the real point of those policies about "no source
> builds
On May 18, 2011, at 12:24 PM, Christopher Browne wrote:
> It'll be time to drop the contrib material from the "core" when that
> shift leads to a 1 line configuration change somewhere that leads to
> packages for Debian/Fedora/Ports drawing their code from the new spot.
>
> I'd fully expect that
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
> The other problem is that the facility we need to provide the most is
> binary distributions (think apt-get). Lots of site won't ever compile
> stuff on their production servers. So while PGXN is a good tool, it's
> not a universal answer.
On May 17, 2011, at 9:44 AM, Peter van Hardenberg wrote:
> My apologies for wading in out of the blue here as a first time poster with
> big demands, but allow me to briefly state my hopes without trying to be too
> proscriptive about particular mechanisms.
You are not alone, I assure you. :-)
On May 12, 2011, at 3:50 PM, Tom Lane wrote:
>> Would changing the versions from 1.0 to 1.0.0 really break anything for
>> those folks?
>
> It would as soon as they needed to do an ALTER EXTENSION UPDATE ..
Ah-ite, screw it then.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-ha
On May 12, 2011, at 3:09 PM, Tom Lane wrote:
> I had somewhat intentionally not numbered them in the same format as the
> main release numbers, because if we did that, people would expect them
> to match the main release numbers.
Well, I think the fact that they're all 1.x managed to do that well
Hackers,
I don't suppose I could convince you to use dotted-decimal version numbers for
the contrib extension versions, rather than numerics, could I? At this point, I
think that would just mean changing them from 1.0 to 1.0.0.
Why? Well, PGXN uses semantic versions, which have this format, so
On May 11, 2011, at 2:47 PM, Robert Haas wrote:
>> Okay, how we add a "revision" key to the control file and extrevision to the
>> pg_extension catalog. Its type can be "TEXT" and is optional for use by
>> extensions.
>>
>> This would allow extension authors to identify the base version of an
On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote:
> So maybe it's half-assed. Maybe the version can be anything but the revision
> must be an integer. Maybe there's a `pg_extension_version($extension_name)`
> function that returns ARRAY[$version, $revision], and the revisi
On May 4, 2011, at 3:04 PM, Alvaro Herrera wrote:
> As someone commented downthread, they also want to have things such as a
> "typeof" operator. It could be used in (say) a plpgsql function to
> choose different branches of code.
FWIW, pg_typeof(any) has been in core since 9.0.
Best,
David
Hey folks,
I'd kind of like to get this issue nailed down soon so I can update the PGXN
HOWTO and illustrate a generally agreed-upon best practice for extension
developers. How *do* we want people to use versions in their extension?
Thanks,
David
On Apr 28, 2011, at 2:16 PM, David E. Wh
On Apr 29, 2011, at 2:07 PM, Tom Lane wrote:
> In particular, src/include/nodes/plannodes.h is pretty well commented.
Ah, that's a useful file to scan, thanks.
> If it's not immediately obvious how that maps to what's shown by
> EXPLAIN, look into commands/explain.c.
Yeah, that's the file I hav
Hackers,
Is there any place where the contents of EXPLAIN nodes are documented? I'm
making a lot of use of the XML format right now to figure out what queries sort
on what tables and with what columns, but I've had to do a lot of
experimentation to figure out what each type of node contains.
F
On Apr 29, 2011, at 8:22 AM, Tom Lane wrote:
> AFAICT the initial prompt is always "mysql> ", so they don't have to
> think hard about how many spaces to insert to make it line up. But
> we could certainly invent a prompt escape that means "as many spaces
> as there are characters in the current
On Apr 28, 2011, at 3:40 PM, Andrew Dunstan wrote:
> It's been pointed out before that plugins (like FDWs) can invent their own
> explain nodes, so we'll never have a canonical list of such nodes.
Oh, interesting. Stil, a list of core nodes is a good 90% solution, IMHO.
Best,
David
--
Sent
On Apr 28, 2011, at 3:02 PM, Peter Geoghegan wrote:
> The code for all nodes is in src/backend/executor.
>
> I think that you will find it useful to look at the big switch
> statements in ExecInitNode() and friends in execProcnode.c .
Yep, same as what I found in src/backend/commands/explain.c.
Hackers,
For my [explanation extension](http://pgxn.org/extension/explanation) I wanted
to put together a list of node types, since I'm always having to figure them
out to decide which nodes I'm interested in. Reading
src/backend/commands/explain.c I assembled this list:
+ Aggregate
+
On Apr 28, 2011, at 7:04 AM, Tom Lane wrote:
> I think what we're discussing here is bug-fix revisions that don't
> affect the SQL declarations for the extension. Presumably, that means a
> change in the C code, so the shared library is the right place to keep
> the revision number. A version nu
On Apr 27, 2011, at 3:28 PM, Josh Berkus wrote:
> Actually, you can already sort of do that using XSLT. So I don't
> necessary think that's a prohibitive idea, depending on implementation.
> After all, many of the new non-relational databases implement exactly this.
The proposed JSON data type
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
> Really, that means you just a sql function to your extension,
> somethign similary to uname -a, or rpm -qi, which includes something
> that is *forced* to change the postgresql catalog view of your
> extension every time you ship a new version (m
On Apr 25, 2011, at 5:49 AM, Robert Haas wrote:
> I think it's a bit awkward that we have to do it this way, though.
> The installed version of the extension at the SQL level won't match
> what the user thinks they've installed. Granted, it'll be in the
> ballpark (1.0 vs 1.0.3, for example) but
On Apr 24, 2011, at 3:03 PM, Tom Lane wrote:
> Yeah. It seems like a bad idea if the distribution "name" doesn't
> include sufficient information to tell which version it contains.
> I had in mind a convention like "distribution version x.y.z always
> contains extension version x.y". Seems like
On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
> Hmm ... it's sufficient, but I think people are going to be confused as
> to proper usage if you call two different things the "version". In RPM
> terminology there's a clear difference between "version" and "release";
> maybe some similar wording sh
On Apr 24, 2011, at 2:46 PM, Tom Lane wrote:
> IMO it'd be better if the bug fix level was tracked outside the
> database, for instance via an RPM package version/release number.
> I'm not sure whether PGXN has anything for that at the moment.
Distributions may have their own versions independent
On Apr 23, 2011, at 1:03 PM, Dimitri Fontaine wrote:
> Daniele Varrazzo writes:
>> For my extension I'm less concerned by having the install sql named in
>> different ways or by the upgrade sql as all these files are generated
>> by scripts. You may find useful this one
>
> You can also generate
On Apr 21, 2011, at 10:06 AM, Robert Haas wrote:
> Heck, even the name "PostgreSQL Experts, Inc." could be taken to imply
> that the rest of us are all chumps.
Send me your résumé, we’ll talk.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Apr 20, 2011, at 8:25 PM, David E. Wheeler wrote:
> Okay. What about building something into PGXS that could handle these kinds
> of things? I just can't help but wonder if there isn't some better way to do
> the kinds of things that Daniele and I have resorted to
On Apr 20, 2011, at 8:04 PM, Daniele Varrazzo wrote:
> Specifically, I parse the version from the control file using:
>
>PGMP_VERSION=$(shell grep default_version pgmp.control | sed -e
> "s/default_version = '\(.*\)'/\1/")
Oh, that's not bad. Thanks.
> so the Makefile doesn't have to be mai
On Apr 20, 2011, at 8:16 PM, Tom Lane wrote:
> I'm not interested in kluging things up after the fact to try to somehow
> reverse that mindset and make pre-extension-world and post-extension-world
> scripts compatible. That looks like long-term pain in return for very
> small short-term gain to m
Hackers,
I finally got round to updating a couple of my extensions to support 9.1
extensions. Unlike the contrib extensions, these needed to target older
versions of PostgreSQL, as well. Case in point, the semver data type; you might
find the Makefile of particular interest:
https://github.c
On Apr 9, 2011, at 2:40 PM, Tom Lane wrote:
> Since ILIKE now responds to collations, it would be nice if the
> case-insensitive regex operators did too. The hard part of that is
> getting the information from src/backend/utils/adt/regexp.c to
> src/backend/regex/regc_locale.c. In principle we c
On Apr 8, 2011, at 8:05 AM, Robert Haas wrote:
>> same mechanism works well in plpgsql and nobody requested a some
>> special shortcut.
>
> I did. That mechanism sucks. But I think we're committed to doing
> what the standard and/or Oracle do, so oh well.
I think I've worked around that in PL/
On Apr 7, 2011, at 6:58 PM, Tom Lane wrote:
> Well, if we're going to consider 100% backwards compatibility a "must",
> then we should just stick with what the submitted patch does, ie,
> unqualified names are matched first to query columns, and to parameters
> only if there's no column match. Th
On Apr 5, 2011, at 1:59 PM, Aidan Van Dyk wrote:
> Versions are useful for figuring out if I should upgrade packages or
> not. But I believe the extension framework has explicitly made the
> "upgrade" problem a manual one at this point, either taking
> destination versions from the control, or th
On Apr 5, 2011, at 3:34 PM, Joshua D. Drake wrote:
> boom, I am in.
>
> Thoughts?
boom, you have patch?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Apr 5, 2011, at 1:42 PM, Aidan Van Dyk wrote:
> Sure, but if you want, the "feature" you can provide can be something like:
> pgtap-1.0 (or any of pgtap-0.2{0,1,2,3,4}).
>
> And if your package is backwards compatable, it could even provide:
> pgtap-0.25
> pgtap-0.24
> pgtap-0.23
I se
On Apr 4, 2011, at 3:57 PM, Tom Lane wrote:
>> I think the general movement is toward *feature* dependancies. So for
>> intstance, an extension can specify what *feature* it requires, and
>> difference "versions" of an extension can provide different
>> "features".
>
> Right.
Sounds like a book
On Apr 4, 2011, at 2:48 PM, Tom Lane wrote:
> Once 9.1 is out, it'll probably be too late to dictate any semantics for
> version numbers, because somebody will have done something incompatible
> with it before 9.2 is released. If we are going to try to insist on
> this, now is the time.
Yes, exa
Hackers,
I wanted to get a (ok, not so) quick note in about this before the beta
dropped. I've been thinking about the "requires" parameter on extensions
control files. Right now it just lists the names of extensions that are
required for the extension to run:
requires = 'foo, bar'
But I'
On Mar 25, 2011, at 11:23 PM, Tom Lane wrote:
> If this were PL/perl, or PL/almost-anything-except-SQL, I could get
> behind such a proposal. But it's not, it's SQL; and SQL doesn't do
> things that way. SQL's idea of disambiguation is qualified names.
>
> And even more to the point: to the ext
On Mar 25, 2011, at 9:12 PM, Robert Haas wrote:
>
> As I've said before, I believe that the root cause of this problem is
> that using the same syntax for variables and column names is a bad
> idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
> or &&foo!!$#? to mean "the parame
On Mar 7, 2011, at 4:41 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> I saw that Tom added the ModifyTable node to EXPLAIN output last week. I'd
>> like to update my explanation extension to use it, but I've no idea what it
>> would look like. Co
Howdy,
I saw that Tom added the ModifyTable node to EXPLAIN output last week. I'd like
to update my explanation extension to use it, but I've no idea what it would
look like. Could someone send me an example in the XML format?
Thanks!
David
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On Mar 4, 2011, at 7:44 PM, Robert Haas wrote:
> So it seems like the only thing that is an absolute must-do is write
> some release notes.
What about this?
> Yeah, the real problem in my mind is not so much citext as whether the
> current representation of a type's collation property is sane in
On Mar 5, 2011, at 10:03 AM, Tom Lane wrote:
> On reflection I think it makes no sense at all to leave those tools
> issuing CREATE/DROP LANGUAGE. We want to move people over to managing
> languages via extensions, and leaving those tools unchanged will not
> serve that goal. However, I don't mi
On Mar 4, 2011, at 8:19 AM, Tom Lane wrote:
> Hmm. Personally I do use createdb/dropdb but never createlang/droplang;
> but I'm well aware that my usage may not be typical. I'm a bit hesitant
> to just go and drop these without any warning. I could see deprecating
> them for a release or two an
On Mar 4, 2011, at 7:43 AM, Tom Lane wrote:
>> Well it's easy to read that the other way round. Is superuser = true
>> means that I need to be a superuser or does it mean that the script will
>> get run as superuser no matter what? Not a huge problem, but still.
>> What about using the PL termin
On Mar 3, 2011, at 2:16 PM, Tom Lane wrote:
> Extensions yes, but not managed with those commands. You'd have to
> switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE
> commands themselves would now only occur within those extension
> scripts.
Ah, I see. So if someone insta
On Mar 3, 2011, at 1:31 PM, Tom Lane wrote:
> However, it does strike me that there is one simple case we could
> support without a great deal of sweat. Namely, what if we allow
> non-superusers to create an extension if all the commands in the script
> are ones they could execute anyway? In par
On Mar 3, 2011, at 11:09 AM, Tom Lane wrote:
> That's not a design, that's just a very arbitrary kluge. And it doesn't
> solve anything at all that we need to solve today, because you can
> already assume that you're running on >= 9.1 just by the fact that
> you're writing an extension. Having a
On Mar 3, 2011, at 10:54 AM, Tom Lane wrote:
>> Which is why my suggestion is pretty much free from any design. Just a list
>> of dependencies, with only a server version number. No other syntax at all.
>> It can be added later.
>
> I basically agree with Robert that "requires = 9.1" is entirel
On Mar 3, 2011, at 10:49 AM, Kevin Grittner wrote:
>> Which is why my suggestion is pretty much free from any design
>
> Now you're scaring me. I read that as "the proposed design is free
> from the influence of any design effort."
No. Just as simple as possible.
> That's precisely how you
> c
On Mar 3, 2011, at 10:32 AM, Robert Haas wrote:
>> Who said anything about full generality? I'm interested in a 90% (or even
>> 99%) solution.
>
> It's pretty important that we don't design ourselves into a corner her
Which is why my suggestion is pretty much free from any design. Just a list o
On Mar 3, 2011, at 10:22 AM, Robert Haas wrote:
> Requires: package
> Requires: package >= minversion
> Requires: package <= maxversion
> Requires: package = exactversion
>
> The usefulness of the first two should be obvious, but the third and
> fourth are needed as well.
In the long term, perha
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> core_requires = 9.0, plpgsql, libxml
>
> As soon as you get there you need an or operator to be able to say 9.0 |
> 9.1, or maybe some comparison operators to say >= 9.0. Remem
On Mar 3, 2011, at 9:55 AM, Dimitri Fontaine wrote:
> Then those should be marked "System" and only get displayed with \dxS,
> or this will completely bloat the extension listings. Also if we get
> there, what about listing all the SQL Standard Features (optional only
> maybe) that are provided b
On Mar 3, 2011, at 9:47 AM, Dimitri Fontaine wrote:
> Then, what about a control file property to cover that?
>
> pl_language = plpgsql
>
> Then when running the script any object attached to the extension that
> is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when
> the pl_l
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> If my extension requires a procedural language, will adding that language to
>> the `requires` control key do what I think it should do?
>
> No.
>
> Probably in future the standa
You should blog this.
David
On Mar 2, 2011, at 11:58 AM, Tom Lane wrote:
> It occurred to me that it might be a good idea to describe how
> I've been testing extension upgrade scripts. So:
>
> 1. Install the 9.0 version of the module in an empty 9.0 database.
> pg_dump this database.
>
> 2. L
It's about dependences.
If my extension requires a procedural language, will adding that language to
the `requires` control key do what I think it should do?
If not, how should one require a PL? Come to think of it, how might I require
other features that might not be included in a particular b
On Mar 2, 2011, at 9:02 AM, Andrew Dunstan wrote:
> That's because David apparently hasn't run update_personality.pl, although he
> has in the past.
Is this something we can run against crazier community members?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
> Collation, not correlation.
Yeah, I'm fat-fingered today.
> The question is what collation property the
> citext type needs to have, and how we get it to have that setting during
> an upgrade from 9.0. See
> http://archives.postgresql.org/message-
On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
> * Collation-related changes still needed in contrib/citext. If we don't
> have this done before alpha4, I'm afraid we'll have to generate a 1.1
> update script to fix it for alpha4 users. I'd just as soon not deal
> with that overhead.
What needs t
On Feb 27, 2011, at 11:43 AM, Tom Lane wrote:
>> XPath is broken? I use it heavily in the Perl module Test::XPath and now, in
>> PostgreSQL, with my explanation extension.
>
> Well, if you're only using cases that work, you don't need to worry.
Okay then.
David
--
Sent via pgsql-hackers mai
On Feb 27, 2011, at 11:23 AM, Tom Lane wrote:
> Well, that's why I asked --- if it's going to be a huge chunk of code,
> then I agree this is the wrong path to pursue. However, I do feel that
> libxml pretty well sucks, so if we could replace it with a relatively
> small amount of code, that migh
On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
>> The best idea I have at the moment is to spell out "data modifying
>> command" (or "statement") rather than relying on the acronym.
>> In the code, we could change hasDmlWith to hasModifyingWith, for
>> example. The error messages could read lik
401 - 500 of 1570 matches
Mail list logo
