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
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
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 a
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 without
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 corresponds
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
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
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
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 30th
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. However
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:
- commandALTER TABLE/ is far faster than a bulk operation.
+ commandALTER TABLE/ (to split out a sub-table from the partitioned
+ table) and commandDROP TABLE/ (to remove a partition altogether)
are
+ both far faster than a
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
---
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 like
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 all.
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 brainz.
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 are
On May 27, 2011, at 2:35 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
no requirement that an OID in the mapping table
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 go away.
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
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 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 to
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 is to
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 wrong),
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
On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com 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. The simple way is to have
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. :-)
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 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
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
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 revision is set
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
extension
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. Wheeler
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
--
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 DB
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.
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 have
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
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 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.
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 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 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 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
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 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 should be
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 minor
On Apr 23, 2011, at 1:03 PM, Dimitri Fontaine wrote:
Daniele Varrazzo daniele.varra...@gmail.com 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
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
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:
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 me.
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
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 to use a PostgreSQL
version
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
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/pgSQL
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. This is
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-keeping
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 see, I get
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 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,
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'm
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 extent
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 parameter
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
On Mar 7, 2011, at 4:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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. Could someone send me an example
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 mind
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 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 terminology
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 and
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
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 by the
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com 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. Remember that
about all
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, perhaps. But
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 of
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
can find
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 entirely
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 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
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 installed
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
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
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. Load
On Mar 2, 2011, at 11:00 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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 standard PLs will be packaged
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 to
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
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 might
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 mailing
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 like
On Feb 21, 2011, at 9:12 AM, Andrew Dunstan wrote:
my $parser= XML::DOM::Parser-new();
my $xp = $parser-parsefile($xmlfile);
my ($provider) = $xp-findvalue(//SERVICE_PROVIDER_CODE);
my ($invoice_num) = $xp-findvalue(//invoice_num);
Not that hard, is it? No regex matching there. :-)
On Feb 21, 2011, at 10:07 AM, David E. Wheeler wrote:
See also
https://github.com/theory/explain-table
Oops, sorry, make that
https://github.com/pgexperts/explain-table
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Feb 21, 2011, at 10:11 AM, David E. Wheeler wrote:
Oops, sorry, make that
https://github.com/pgexperts/explain-table
And now I've renamed it (sorry) and released it on PGXN. New links:
https://github.com/pgexperts/explanation
http://master.pgxn.org/dist/explanation/
Best,
David
On Feb 17, 2011, at 11:28 AM, Tom Lane wrote:
The status of that patch is that Tom promised to look at it two months
ago and hasn't. It would be nice if someone else could pick it up.
I'm pedaling as fast as I can, honestly
Tom leaves everything on the road.
On Feb 17, 2011, at 2:50 PM, Tom Lane wrote:
I observe the following discrepancy between the 9.0 and 9.1 citext
install scripts:
***
*** 52,58
STORAGE= extended,
-- make it a non-preferred member of string type category
CATEGORY = 'S',
!
401 - 500 of 1565 matches
Mail list logo
