On Mar 31, 2009, at 8:34 AM, Sam Mason wrote:
What do you really expect to be returned for things like
select count_elements(string_to_array('butter,tea,milk',','))
3 = {butter,tea,milk}
select count_elements(string_to_array('butter,tea',','))
2 = {butter,tea}
select
On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:
+1. I find this argument much more compelling than anything else
that's been offered up so far.
Yeah. It seems to me that if you consider only the case where the
array
elements are text, there's a weak preference for considering '' to
be a
On Apr 1, 2009, at 10:09 AM, Tom Lane wrote:
Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is meant to be
useful
for lists of anything except text. I agree you could argue that it
isn't.
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the difference between a empty string to a
string with many blank entries
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example
of something like '1,2,,4'.
I can't see that there's any way to do this in SQL regardless of how
we define this operation.
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does). The former is sounding
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the right thing more often
On Apr 6, 2009, at 5:48 PM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
At the VERY LEAST, can we PLEASE have the zone.tab file
INSTALLED WHERE IT BELONGS rather than simply ignored, so that even
if
further requests to include the information in a system view go
On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote:
In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.
My impression was that among the change options, 2b had the most
support (it is the most useful for the use-cases I've
On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
Agreed, it seems to me that a patch to install zone.tab during make
install could be applied at this time (before beta so that packagers
don't complain that we didn't give them time to fix their file lists).
A more complete patch can be
On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-case for the data is
unconvincing.
It seems to me that the immediate patch to simply copy zone.tab has no
effect on the API.
On Apr 14, 2009, at 9:26 AM, Tom Lane wrote:
Another question is what is the purpose of a database? To me it
would
be quite the wrong thing for the DB to not store what is presented, as
long as it's considered legal. Normalization of legal variant forms
seems pretty questionable. So I'm
On Apr 14, 2009, at 11:22 AM, Tom Lane wrote:
BTW, does anyone know whether Unicode includes the ASCII control
characters ... ie, is \u0009 a name for tab? If so, maybe this
syntax is in part an attempt to cover that use-case in the standard.
Yes, you can use, e.g., #x0009; in HTML to
On Apr 14, 2009, at 11:10 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a good case for some functions implementing the
various
Unicode normalization functions, though.
I have no objection to that so long as the code footprint is in line
with the utility
On Apr 15, 2009, at 4:45 AM, Sam Mason wrote:
Doh, yes it does doesn't it. Sorry I searched for a bit and failed to
find anything before. Looks as though the signal to noise ratio was
far
too low as I've just searched again and found a (single) reference to
their docs describing the
On Apr 23, 2009, at 12:22 AM, Heikki Linnakangas wrote:
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It
depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) 0 AS one;
The comment in varstr_cmp()
On Apr 23, 2009, at 12:00 PM, Tom Lane wrote:
You can get around this by cloning template0 instead of template1
(we assume template0 contains nothing that's encoding-specific).
Possibly the docs will need to be improved to emphasize that.
I was just about to suggest that. With this change,
On May 1, 2009, at 10:38 AM, Andrew Dunstan wrote:
Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On May 1, 2009, at 8:38 AM, Robert Haas wrote:
Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow
On May 1, 2009, at 10:54 AM, David Fetter wrote:
foreach my $element (@array) {
# clear, short, idiomatic code here
}
instead of Rube Goldberg constructs like this:
my $i;
for ($i=0; $i = $#array; ++$i)
{
# kludges up down and sideways here
}
is a good idea because it makes it easier
On May 7, 2009, at 10:18 AM, Tom Lane wrote:
Actually, there's another issue that comes to mind here: since we are
relying on platform-dependent locale names, including those in the
dump
is going to pose a severe problem for porting dumps across platforms
(where different platform could even
On May 7, 2009, at 12:32 PM, Tom Lane wrote:
Or we could try to make the user-visible locale names
platform-independent in the first place, a la David's not-silly-at-all
suggestion.
Actually, what I was thinking of was using a platform-independent
locale infrastructure: the inconsistency in
On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote:
(You can't be serious that for reverting a WC file to the repository
state you use git checkout?)
Why not? The purpose of the operation is to get a file from the
repository.
It's not much different whether you do it the first or the
On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about
On May 27, 2009, at 1:50 AM, Dimitri Fontaine wrote:
The moment you're adding specific schemas where to put extensions
into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid
having
those people to care
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement.
Yeah, I likes.
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea,
as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and
On May 28, 2009, at 12:22 PM, Tom Lane wrote:
What you need is a test that looks at the SQLSTATE code, and little
if anything else.
Yes, and throws_ok() supports that:
SELECT throws_ok( 'SELECT 1 / 0', '22012' );
Best,
David
--
Sent via pgsql-hackers mailing list
On May 28, 2009, at 12:53 PM, Kevin Field wrote:
Can pgTap check for a regex instead if just a string?
That's the other option, if the pgTAP author is willing...if the
SQLSTATE thing doesn't work out I guess we'll have to go down that
road.
Patches welcome. ;-)
On May 28, 2009, at 11:27 AM, Greg Stark wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com
wrote:
Yes, just as long as your extensions schema doesn't turn into a
bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up
with a
giant
On May 28, 2009, at 11:38 AM, Tom Lane wrote:
I suppose there might be some use-case involving concurrent
installation
of multiple versions of the *same* extension, but I'm not sure we
should
be designing around that as a key case.
Agreed. One thing at a time.
Best,
David
--
Sent via
On May 28, 2009, at 12:10 PM, Robert Haas wrote:
It feels like a Java CLASSPATH,
or installing every application into /usr/local/application-name so
that your path has 50 bin directories in it.
+1 Yeah, that was my trouble with it.
Best,
David
--
Sent via pgsql-hackers mailing list
On May 28, 2009, at 12:33 PM, Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Well, if it's
On May 29, 2009, at 4:59 AM, Kevin Field wrote:
http://github.com/theory/pgtap/tree/master/
I'm getting a new version ready to release as I type.
Thanks, great to know. :) Although, I do think changing plperl is
the more proper option, so I'm going to try there first...
I added
On May 29, 2009, at 3:24 AM, Peter Eisentraut wrote:
Yeah, to reiterate what I posted elsewhere, perhaps it'd be a good
idea to
give up on the search path idea altogether and think more in terms
of an
import facility like Python, Java, and sometimes Perl have.
+1
Actually, Perl's is
On May 29, 2009, at 3:38 AM, Dimitri Fontaine wrote:
PS: we still have to provide users with easy tools to (dynamically)
manage search_path, don't we?
(I prefer not to start the search_path management tool ideas right
here).
Yes, we do, and that's what at least half this thread is about.
On May 29, 2009, at 12:41 PM, Greg Stark wrote:
That said, I don't mind the idea of having a way to push things onto
search path like you often do in sh using PATH=/foo/bar:$PATH.
Yes, +1.
But I think the only reason to install something into a separate
schema is precisely if you *want*
On May 29, 2009, at 2:45 PM, Greg Stark wrote:
2) Normally programming languages do early binding so as soon as the
code is parsed references are resolved. You can't later define a new
function earlier in the search path and have it take over references
that have were previously referring to
On May 29, 2009, at 2:52 PM, Josh Berkus wrote:
a) the ability to push a schema onto the current search path
b) the ability to pull a schema off the current search path
push, pop, shift, unshift. :-)
Come to think of it, I want these for arrays, too. ;-)
Best,
David
--
Sent via
On May 29, 2009, at 5:16 PM, Greg Stark wrote:
On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler da...@kineticode.com
wrote:
On May 29, 2009, at 2:52 PM, Josh Berkus wrote:
a) the ability to push a schema onto the current search path
b) the ability to pull a schema off the current search
On May 31, 2009, at 3:47 PM, Greg Stark wrote:
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus j...@agliodbs.com
wrote:
This assumes that all users should have access to the same public
APIs as
all other users. Real applications are more complex.
Well the goal is to make them simpler. I
On Jun 2, 2009, at 8:43 AM, Tom Lane wrote:
Each of these is configured (using --prefix) to install into a
separate
installation tree. So I can switch my attention to one branch or
another by cd'ing to the right place and adjusting a few environment
variables such as PATH and PGDATA.
Yeah,
On Jun 2, 2009, at 9:03 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
That's what I'd gathered, and frankly it is not an acceptable answer
On Jun 2, 2009, at 9:16 AM, Alvaro Herrera wrote:
Well, you can have as many clones of a repository as you like. You
can
keep one with master checked out, another with rel8_3, another with
rel8_2, etc. You'd just have to write a script to keep them in sync
(shouldn't be too difficult, each
On Jun 2, 2009, at 9:23 AM, Aidan Van Dyk wrote:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
But that looses his configured and compiled state...
But git isn't forcing him to change his workflow at all...
On Jun 2, 2009, at 2:31 PM, Tom Lane wrote:
It's a bit premature to speculate about alternate history tools when
we haven't figured out what the repository is going to look like.
Right
at the moment I'm much more concerned about the question of supporting
a checkout-per-branch workflow.
On Jun 2, 2009, at 3:11 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Perhaps there's a master repository that corresonds to CVS HEAD, and
then release branches are actually separate git repositories.
Yeah, I was speculating about that one too. It might be workable.
Just
On Jun 2, 2009, at 3:33 PM, Tom Lane wrote:
A back-branch-only fix would look the same except for not having any
unannotated filenames. I'm too lazy to go trolling for one just now.
God Tom, you're such a bloody slacker. Sheesh!
It's also possible to get it to produce histories that
On Jun 2, 2009, at 3:56 PM, Tom Lane wrote:
Well, it's not like CVS makes it easy ... cvs2cl is about 50K of perl,
and is not very speedy or without bugs :-(. So maybe we are setting
the goalposts in the wrong place by supposing that the lowest-level
git
history needs to be exactly what's
On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote:
Umm, no. there are *no* ,v files in my working copies (I just
checked, to make sure I wasn't on crack). The repository has them,
but the working copy does not. SVN does keep the equivalent - that's
how you can work offline for doing things
On Jun 2, 2009, at 4:13 PM, Tom Lane wrote:
I think you missed the part of the discussion about not wishing to
share
a single working directory across all the branches.
No, I was just ignoring it for the moment to focus on the commit and
history issue.
The time to rebuild
derived files
On Jun 2, 2009, at 4:39 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths
On Jun 2, 2009, at 5:26 PM, Josh Berkus wrote:
Tom, all,
More suggested dispositions:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows
On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
It seems we have two reasonable possibilities for 8.4: revert that
patch
and keep contrib/intarray's behavior the same as it was, or leave the
patch in and document that there was a behavioral change.
You can't keep the patch and update intarray
On Jun 10, 2009, at 11:06 PM, KaiGai Kohei wrote:
The SE-PostgreSQL patches are updated as follows:
Kohei-San,
I've no idea whether SE-PostgreSQL will ever make it into the core
distribution, and have no way to really determine whether or not it's
a good idea, but I did want to say:
I
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
That Tom Lane, so warm and cuddly!
David
--
Sent via
Howdy,
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's direction argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
I assume that they should be FORWARD and
On Jun 21, 2009, at 5:07 PM, David E. Wheeler wrote:
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's direction argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
I
On Jun 23, 2009, at 6:25 AM, Tom Lane wrote:
We spun an 8.4RC2 tarball, mainly to check that Peter's recent fixes
to the man page generation process actually worked. There will not be
binary builds of RC2, but if anyone who's building from source wants
to
double check it, it should be on
On Jun 23, 2009, at 10:44 AM, Dimitri Fontaine wrote:
The contenders are extension, module, bundle and package. My vote is
extension.
+1
== v1.0 goals
We're not trying to be feature complete on first round.
* must have
- dump restore support (when upgrading a cluster or just restoring)
On Jun 23, 2009, at 2:06 PM, Dimitri Fontaine wrote:
It'd be nice if it supported other core languages like PL/Perl, but
it's okay if it doesn't on the first round (I'd likely want to use
some CPAN modules in a PL/Perl extension, anyway).
At first sight I though you were talking about a
On Jun 23, 2009, at 3:02 PM, Dimitri Fontaine wrote:
If we happen to accept the debian policy versioning scheme, then the
hard work is already done for us, it seems:
http://packages.debian.org/fr/sid/postgresql-8.3-debversion
As long as we don't need to implement a new data type, fine.
On Jun 24, 2009, at 12:59 AM, Dimitri Fontaine wrote:
are you aware of the enormous job that will imply for core team?
I'm not saying I want core to take care of all pgfoundry projects that
will make them available as extensions, but to have contrib/ made
extensions and have core if possible
On Jun 24, 2009, at 2:07 PM, Andrew Dunstan wrote:
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then
there are addons, such as you find on CPAN.
Actually, the lesson slowly emerging in the Perl community is
On Jun 24, 2009, at 2:12 PM, Dimitri Fontaine wrote:
The core team isn't appropriate for this. We'd start a new
committee/list somewhere instead, and it would be part of the same
effort which produces a recommended list of extensions and
drivers for packagers.
It'd still deprecate
On Jun 24, 2009, at 2:41 PM, Andrew Dunstan wrote:
I agree they have too many. I think moving to none would be a
mistake, though. Would they even drop things like Dynaloader or
ExtUtils::MakeMaker? That would be crazy, IMNSHO. I think there's a
sweet spot here and we are not very far away
On Jun 24, 2009, at 3:09 PM, Andrew Dunstan wrote:
Well, I think in our case that would be going too far. I think there
is a very good case for keeping a few key extensions in core both as
exemplars and to make it easy to validate the extension mechanism
itself. There have been suggestions
On Jun 24, 2009, at 3:41 PM, Andrew Dunstan wrote:
We have been conservative about this in the past and there is no
reason to expect we will not be in the future. If anything, we are
likely to become more so.
Good, perfect.
Best,
David
--
Sent via pgsql-hackers mailing list
On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
Anything is possible :-). Better to ask someone with more perl
expertise than me how much effort it might take to have the
On Jun 25, 2009, at 7:16 AM, Tom Lane wrote:
The problem is, I think, that the Makefile format is way too
flexible.
I think the contrib makefiles are considered to be our standard test
suite for PGXS. If a 3rd-party makefile is doing anything not
represented in contrib, it's not guaranteed
On Jun 25, 2009, at 10:10 AM, Tom Lane wrote:
Is there no platform-independent build system we could take advantage
of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
Might it be worthwhile just for the
Howdy,
I'm working on functions to compare result sets for pgTAP. In the
process, I found what appears to be an inconsistency in error handling
when comparing incomparable results. I'm testing in 8.4RC2, but the
issue may go back for all I know. Perhaps it's intentional?
This is what I
On Jun 30, 2009, at 10:28 AM, Tom Lane wrote:
VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
Throws 42601 SYNTAX ERROR.
Not for me:
regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
ERROR: each EXCEPT query must have the same number of columns
Turn on verbosity:
try=# \set
]On Jun 30, 2009, at 11:00 AM, Tom Lane wrote:
Oh, you're complaining about the SQLSTATE not the error text.
I guess that to the extent that any actual thought went into it
(which may not have been much) the reasoning was that you'd have to
change the syntax of your query in order to fix this.
On Jun 30, 2009, at 11:18 AM, Tom Lane wrote:
So really what you're wishing for is that we treat different-numbers-
of-
columns as a whole new SQLSTATE inside category 42. What's the
argument
for needing to handle this differently from DATATYPE_MISMATCH?
For my results_eq() in pgTAP, it
On Jun 30, 2009, at 11:27 AM, David E. Wheeler wrote:
# Failed test 148
# Number of columns differs between queries
# have: 4 columns
# want: 3 columns
# Failed test 149
# Column types differ between queries
# have: (integer,text
On Jun 30, 2009, at 11:46 AM, Tom Lane wrote:
For my results_eq() in pgTAP, it could output different diagnostics.
Well, that's not terribly compelling ;-).
Pllt.
I wouldn't have any big
objection to splitting out ERRCODE_COLUMN_COUNT_MISMATCH as a separate
SQLSTATE for 8.5 and
On Jun 30, 2009, at 11:48 AM, Tom Lane wrote:
Is there a way
to get a RECORD object to tell me what data types it contains?
Not at the SQL level. Of course, if you're writing C, you can do
something similar to what record_eq and friends do.
Pity. I'm trying to keep C out of pgTAP (for the
On Jun 30, 2009, at 11:54 AM, David Fetter wrote:
# Failed test 148
# Number of columns differs between queries
# have: 4 columns
# want: 3 columns
Shouldn't that just read:
have: (int, int, text, point)
want: (int, int, text)
Yes, that's my ideal, but
On Jun 30, 2009, at 1:40 PM, David Fetter wrote:
Yes, that's my ideal, but Tom says I need to write C code to get that
information from RECORD objects, alas. :-(
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question. But yes, I think it'd be
On Jun 30, 2009, at 3:05 PM, David Fetter wrote:
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question.
I was thinking of this as part of PgTAP.
Oh. There is a piece of C, but it's just an implementation of
pg_typeof() so that pgTAP can use
On Feb 6, 2009, at 10:54 AM, David E. Wheeler wrote:
On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote:
Oh. That seems kind of odd?can you hang onto the patch until 8.4 is
released, then? This must happen all the time, no?
OK, I will hang on to it, but I will have to mention it is only
On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
released. Is that supposed to be today?
The FAQ is on the wiki now ... fix it yourself.
It is? When did that happen?
Best,
David
--
Sent via pgsql-hackers mailing list
On Jul 1, 2009, at 9:27 AM, Tom Lane wrote:
It is? When did that happen?
http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php
Thanks. Change added to the wiki.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
This code:
CREATE OR REPLACE FUNCTION foo() returns boolean as $$
DECLARE
have_rec record;
want_rec record;
BEGIN
have_rec := row(1, 2);
want_rec := row(3, 5);
RETURN have_rec IS DISTINCT FROM want_rec;
END;
$$ language plpgsql;
On Jul 1, 2009, at 11:47 AM, Merlin Moncure wrote:
fyi: works in 8.4, as part of a broad fix of composite type
comparison ops
whoops, you knew that already :-). one possible workaround is:
select $1::text is distinct from $2::text
Yes, and that's what I'm doing, although it is
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL. For
example, does 7.4 still get bug fixes and minor releases? If not, how
does one know when support for a major version has been dropped?
On Jul 7, 2009, at 12:49 AM, Albe Laurenz wrote:
Is this a known issue in 8.3? If so, is there a known workaround?
The change is probably here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00110.php
So I think it is safe to argue that this is not a bug in 8.3, but an
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to
desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large
set
of back branches, and a
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public
notice of any EOL for a branch. At least a couple of months,
preferably. If the lifetime were absolutely fixed it might not
matter so much, but as it isn't I think we owe that
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it? And it only goes back to 8.0 and it served with
the text/html content-type.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
control over scheduled
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote:
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have
formal
control over scheduled maintenance expirations…
The web team already has a table, and it is published
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for EOL:
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
After the above dates, the
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote:
I don't mind the idea of saying our intention is to support new
releases for about five years, or something equally squishy.
But a list of dates in black and white does not look reasonable,
especially not dates that are four or five years out for
On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where
I want directly.
Hey Andrew,
On Jul 16, 2009, at 7:17 AM, Andrew Gierth wrote:
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
This looks great, Andrew, thanks. Here's what I did to try it out:
* I built a simple database with a table with an (old) hstore
701 - 800 of 1565 matches
Mail list logo
