On Jan 2, 2012, at 10:47 AM, Peter Eisentraut wrote:
* Named arguments in function calls: done since PG 9.0; and we're
phasing out the = operator.
We don’t support `=` for params yet, right? Still just `:=`?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Dec 22, 2011, at 7:48 AM, Oleg Bartunov wrote:
we have pgfoundry project http://pgfoundry.org/projects/dbsamples/.
Since your sample database is very important (for me also), I suggest to use
this site.
Or PGXN.
http://pgxn.org/
You can register an account to upload extensions like you
On Dec 19, 2011, at 9:00 PM, Robert Haas wrote:
+1, though I think the core type will at least need some basic operators and
indexing support.
And I'm willing to do that, but I thought it best to submit a bare
bones patch first, in the hopes of minimizing the number of
objectionable
On Dec 20, 2011, at 2:13 AM, Magnus Hagander wrote:
Yes, that's why I said few not none.
Though in my experience, most companies are a lot more restrictive
about addons to their database than addons to their development
environments.
Yeah, we’re getting off-topic here, so I’ll just say
On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
Are people explicitly asking for a) *JSON* datatype or b) a type that lets
you store arbitrary complex semi-untyped data structures?
Yes.
if b) then this might get a lot more interesting
JSON is the most popular/likely way to represent
On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:
We can hopefully get around this for the extensions in contrib (and
reasonably well has already), but few large companies are going to be
happy to go to pgxn and download an extension that has a single
maintainer (not the team, and in most
On Dec 19, 2011, at 3:39 PM, David E. Wheeler wrote:
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to describe it as a subset of JS or ECMAScript.
Bah, it says
On Dec 19, 2011, at 2:49 AM, Dimitri Fontaine wrote:
My understanding is that JSON is a subset of ECMAscript
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to
On Dec 17, 2011, at 3:53 AM, Simon Riggs wrote:
Which looks very good.
Love having the start here. I forwarded this message to Claes Jakobsson,
creator of the jansson-using pg-json extension. He’s a bit less supportive. He
gave me permission to quote him here:
Frankly I see the inclusion of
On Dec 17, 2011, at 7:40 PM, Tom Lane wrote:
Well, I think that that's exactly the question here: if we do something
in core, will it foreclose options for people who want to do add-ons?
Why would it? They would just have to use a different name.
Best,
David
--
Sent via pgsql-hackers
On Dec 13, 2011, at 8:21 PM, Tom Lane wrote:
I'm not sure whether we'd want something like this in core, so for a
first go-around, you might want to consider building it as an
extension. ... I'm not sure you
need NOTIFY for anything anywhere in here.
Actually, what I'd suggest is just
On Dec 14, 2011, at 6:31 AM, Andrew Dunstan wrote:
Thanks. Committed with that changed, although we seem to be getting
altogether too obsessive about white space, IMNSHO.
If that’s all there is to complain about, I think it’s a pretty good sign. ;-P
David
--
Sent via pgsql-hackers mailing
On Dec 12, 2011, at 7:42 PM, Alvaro Herrera wrote:
I remember there was the idea of doing something like this for regexes
-- have a specialized data type that saves the trouble of parsing it.
I imagine this is pretty much the same.
Nobody got around to doing anything about it though.
On Dec 12, 2011, at 12:54 PM, Robert Haas wrote:
I don't think that's going to fly, because
=(text,text) probably has different semantics from =(json,json).
No question:
david=# select '{foo: 1, bar: 2}'::json = '{bar: 2, foo: 1}'::json;
?column?
--
t
(1 row)
On Dec 12, 2011, at 3:55 PM, Peter van Hardenberg wrote:
I'd like to make the controversial proposal that the URL prefix should
be postgres: instead of postgresql:. Postgres is a widely accepted
nickname for the project, and is eminently more pronounceable. Once
the url is established it will
On Dec 12, 2011, at 4:51 PM, Peter van Hardenberg wrote:
Because we haven't heard from him in a while we've been using PL/V8 to
validate a JSON datatype simulated by a DOMAIN with a simple
acceptance function. (See below.) This is not ideally performant but
thanks to V8's JIT the JSON parser
On Nov 28, 2011, at 4:56 AM, Andrew Dunstan wrote:
OK, it's done.
Andrew++ Thanks!
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 Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
Has this been backpatched as well?
It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think it should be
back-patched all the way.
Best,
David
--
Sent via pgsql-hackers mailing list
On Nov 23, 2011, at 10:33 PM, Tom Lane wrote:
Now you could argue that for performance reasons everybody should write
their canonicalization functions in C anyway, but I'm not sure I buy
that --- at the very least, it'd be nice to write the functions in
something higher-level while
On Nov 11, 2011, at 4:27 AM, Dimitri Fontaine wrote:
EXTENSION= pgtap pgtap-core pgtap-schema
See contrib/spi/Makefile for an exemple of that.
Okay, good, it *should* work then.
make
Makefile:79: *** multiple target patterns. Stop.
So is that not supported? If not, why not?
On Nov 11, 2011, at 9:20 AM, David E. Wheeler wrote:
Can we see your Makefile?
Right here:
https://github.com/theory/pgtap/blob/master/Makefile
Oy, this is stupidly my fault. I blame the late hours and the second stout.
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql
On Nov 11, 2011, at 11:04 AM, Dimitri Fontaine wrote:
EXTENSION= pgtap pgtap-core pgtap-schema
https://github.com/theory/pgtap/blob/master/Makefile
I don't see the line above in the file you linked. The content of the
Makefile I just read is not using multiple extensions at all,
Hackers,
I’m preparing a new release of pgTAP, and have started breaking it down into
smaller extensions. I’ve been planning to have them all in one distribution
file for now, but it seems that one cannot specify multiple extension names in
the EXTENSION variable. In my Makefile, I have
Hackers,
So after Tom made -- the separator between an extension name and the version
information in extension file names -- because one might use - in the name
itself, but probably not -- -- it seems that the dash is not actually allowed:
create extension pgtap-core;
ERROR: syntax
On Nov 10, 2011, at 9:45 PM, Itagaki Takahiro wrote:
Parser error?
You need double-quotes around the name:
=# CREATE EXTENSION uuid-ossp;
CREATE EXTENSION
Ah! Okay, thank you!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Nov 8, 2011, at 2:54 PM, Stephen Frost wrote:
So the question is, would a
patch which does the first two without the third be accepted by the
community?
+1 Definitely.
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the
On Nov 8, 2011, at 3:25 PM, Josh Berkus wrote:
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
schedule-driven (instead of trigger-driven) MVs..? Not to try to
feature-creep this on you, but you might consider
On Nov 8, 2011, at 4:23 PM, Josh Berkus wrote:
Well, there has to be some way to refresh an MV at regular intervals, no?
For periodic update matviews, yes. However, Kevin needs only produce
the command/function call for updating a generic periodic matview. He
doesn't need to provide a
On Nov 3, 2011, at 4:59 AM, Heikki Linnakangas wrote:
I've committed this now, after some more cleanup. I removed the selectivity
estimation functions from operators where they were bogus, so writing those
is a clear TODO. But that can well be done as a separate patch.
Thanks!
Woo!
On Nov 1, 2011, at 11:19 AM, Robert Haas wrote:
Fair enough.
So, I tried to work up a patch for this, but I'm actually a bit
confused about what needs to be done here. I'll attach what I've got
so far as a starting point for discussion.
Looks reasonable, if verbose. (Yes, the extension
On Oct 30, 2011, at 11:54 AM, Robert Haas wrote:
If you know that you want all fields except X, Y and Z, why should you be
forced to manually cut and paste all the other fields into the view
definition? That's wasted time and effort that could better be spent
elsewhere.
I agree. This
On Oct 27, 2011, at 9:18 AM, Tom Lane wrote:
So I'm going to go off and do that, but I wonder whether anyone thinks
this is sufficiently important to back-patch. I'm inclined to think
that back-patching isn't a good idea, because changing the
representation of PLpgSQL_stmt_if will break (at
Suggested doc “patch”:
grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
Best,
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 Oct 26, 2011, at 2:06 PM, Andrew Dunstan wrote:
Suggested doc “patch”:
grep -lri 'can not' doc | xargs perl -i -pe 's/can not/cannot/g'
Why? can not is perfectly grammatical AFAIK.
True, but there's a logic issue. Take this example from doc/src/sgml/func.sgml:
para
On Oct 26, 2011, at 2:58 PM, Tom Lane wrote:
I read this as equivalent to can be not released. Which of course is
silly, so as I read it I realize what it means, but it trips up my overly
logical brain. It interrupts the flow. There is no such confusion in cannot
be released and thus no
Hackers,
We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
lines like these:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
ALTER ROLE dude SET default_tablespace TO
On Oct 19, 2011, at 2:13 PM, Tom Lane wrote:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
ALTER ROLE dude SET default_tablespace TO 'users';
I'm beginning to think that the correct
On Oct 13, 2011, at 11:02 AM, Tom Lane wrote:
I'm working through this patch now. Does anyone object to having the
array-to-non-array-result-type and hash-to-non-rowtype-result-type cases
throw errors, rather than returning the rather useless ARRAY(...) and
HASH(...) strings as pre-9.1 did?
On Oct 13, 2011, at 11:25 AM, Tom Lane wrote:
Certainly not in 9.2, no. Not sure about 9.1, though.
Well, right now 9.1 is returning some rather random results. If we
don't change it, someone might claim that later releases ought to be
compatible with that ...
Okay then, works for me.
D
On Oct 12, 2011, at 2:16 AM, Amit Khandekar wrote:
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
$_SHARED{myquote} = sub {
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
return '$arg';
};
$$ LANGUAGE plperl;
SELECT myfuncs(); /* initializes the function
On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
Well, the real question is why a function declared to return VOID cares
at all about what the last command in its body is. If this has changed
since previous versions then I think it's a bug and we should fix it,
not just change the example.
It
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
install a new one so we still need to point to the one in privlib.
Also xsubpp is not executable so the test should be -r or something.
Also don't think we should change
On Oct 5, 2011, at 7:36 PM, Robert Haas wrote:
The open commitfest? Even if its an important bug fix that should be
backpatched?
Considering that the issue appears to have been ignored from
mid-February until early October, I don't see why it should now get to
jump to the head of the
On Oct 6, 2011, at 9:46 AM, Tom Lane wrote:
+1. However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining = operator from hstore
in 9.2:
Fair enough.
Would it then be added as an alias for := for named function parameters? Or
would
On Oct 6, 2011, at 10:37 AM, Tom Lane wrote:
Would it then be added as an alias for := for named function parameters? Or
would that come still later?
Once we do that, it will be impossible not merely deprecated to use =
as an operator name. I think that has to wait at least another
On Oct 6, 2011, at 10:46 AM, Tom Lane wrote:
Okay. I kind of like := so there's no rush AFAIC. :-)
Hmm ... actually, that raises another issue that I'm not sure whether
there's consensus for or not. Are we intending to keep name := value
syntax forever, as an alternative to the standard
On Sep 25, 2011, at 9:58 PM, Itagaki Takahiro wrote:
I'd like to support UTF-8 text or csv files that has BOM (byte order mark)
in COPY FROM command. BOM will be automatically detected and ignored
if the file encoding is UTF-8. WIP patch attached.
By my reading of
On Sep 22, 2011, at 9:53 AM, Josh Berkus wrote:
Then the question is: does it find only #2 via polymorphic lookup, or does
it think that either #1 or #2 could work (because text supports an implicit
cast to citext, IIRC). If it's more than one it's an error. Not sure if the
same issue
On Sep 22, 2011, at 10:11 AM, Josh Berkus wrote:
That's what tests are for.
So, tell me how to write a test to check which function is being used.
Just write some comparisons like upthread, and see if the output is f or t. Put
them into sql/citext.sql.
Best,
David
--
Sent via
On Sep 22, 2011, at 10:50 AM, Josh Berkus wrote:
Just write some comparisons like upthread, and see if the output is f or t.
Put them into sql/citext.sql.
Oh, ok. I thought you meant checking the actual function call.
Tests go in the main SQL file? Shouldn't they have their own file?
On Sep 22, 2011, at 11:07 AM, Alvaro Herrera wrote:
That is the test file. The main SQL file is citext--1.0.sql. You'll actually
need to bump the version number to 1.1, rename that file to citext--1.1.sql,
and also add them to a citext--1.0--1.1.sql. There probably also needs to be
a
On Sep 22, 2011, at 11:14 AM, Kevin Grittner wrote:
No, because if 1.1 was installed on 8.4, you'd need the commands
to move all its functions into the extension, not re-create them.
Shouldn't a version installed on 8.4 be installed as unpackaged?
Doesn't citext--unpackaged--1.0.sql contain
On Sep 22, 2011, at 11:23 AM, Robert Haas wrote:
I believe the point David is trying to make is that someone might take
an 9.2 version of a contrib module and manually install it on an 8.4
server by executing the install script, perhaps with some amount of
hackery.
Right.
But I don't think
On Sep 21, 2011, at 6:12 PM, Tom Lane wrote:
Any idea of how to test for that? What kind of situations would make
things difficult for the parser?
Not sure, but it would be underspecified cases such as 'x' = 'x' that
might have trouble. I may be worrying over nothing --- I'm just trying
Hackers,
Since installing Perl 5.14.1, I installed newer version of ExtUtils::ParseXS
from CPAN. I installed it with `make install UNINST=1`, which removes the copy
of xsubpp that ships with core Perl. This results in an error during PostgreSQL
`make`:
make -C plperl install
gcc -O2 -Wall
On Sep 15, 2011, at 4:41 PM, Alex Hunsaker wrote:
ExtUtils searches @INC, privlibexp maybe we should do that?
Yes, I just got an email from David Golden to that effect. So perhaps the
attached patch is better?
Best,
David
xsubpp2.patch
Description: Binary data
--
Sent via pgsql-hackers
On Sep 14, 2011, at 5:49 AM, Kaare Rasmussen wrote:
[brief]: http://postgresopen.org/2011/schedule/presentations/83/
You list Job scheduling as one item here,
snip
but not here
Here's my preliminary list:
Could you expand your idea about this here?
It was something suggested to me on IRC a
On Sep 13, 2011, at 9:43 AM, Hannu Krosing wrote:
Hannu Krosing / 2ndQuadrant
* more enhancements to pl/python - use real function arguments,
store modules in database, direct support for postgresql types,
operators and functions, automatic startup command,
automatic ORM from table
On Sep 13, 2011, at 3:12 PM, Kevin Grittner wrote:
And here:
http://www.pgxn.org/tag/foreign%20data%20wrapper/
A shorter URL with more results:
http://www.pgxn.org/tag/fdw
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sep 12, 2011, at 9:50 AM, Dimitri Fontaine wrote:
Thanks to Greg Smith for adding a few bonus ideas I hadn't thought of. What
else have you got? I don't think we necessarily have to limit ourselves to
core features, BTW: projects like PostGIS and pgAdmin are also clearly
popular, and new
On Sep 12, 2011, at 6:01, Peter Eisentraut pete...@gmx.net wrote:
Column-level collation support already exists.
Yeah, just realized that. I mention to say table or column-level encoding.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Sep 12, 2011, at 9:41 PM, Magnus Hagander wrote:
I'm not looking for funding (probably couldn't take it if I was offered
it, heh), so I'm not sure if it should be included, but I'm still
planning to dig into revamping the logging system (if I can ever manage
to get out from under my
Hackers,
Later this week I'm giving a [brief][] for an audience of what I hope will be
corporate PostgreSQL users that covers how to get a feature developed for
PostgreSQL. The idea here is that there are a lot of organizations out there
with very deep commitments to PostgreSQL, who really
Interesting.
http://pgxn.org/dist/pg-json/
Best,
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 Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
When it gets to the timezone America/Chicago at the end, this is
handled in the DTK_DATE case, because of the /. But because ptype is
still set, it is expecting this to be an ISO time, so it errors out.
Do we actually *want* to support this?
On Aug 23, 2011, at 8:31 AM, Tom Lane wrote:
One of my goals for the extensions feature has been that we should be able
to get rid of the pg_pltemplate system catalog, moving all the information
therein into languages' extension definition files. This would allow
third-party procedural
On Jul 14, 2011, at 9:53 AM, David E. Wheeler wrote:
(2011/07/14 3:49), Thomas Lotterer wrote:
Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...
Ah, good news, thanks.
Where should I report stuff like this in the future? I sent a message about
this to r
On Aug 17, 2011, at 9:06 AM, Andrew Dunstan wrote:
[empty arrays returned are not handled correctly]
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also adds some
additional comments)
Applied, thanks.
Awesome, thanks!
On Aug 12, 2011, at 5:02 AM, Marko Kreen wrote:
My point was that giving such open-ended list of algorithms
was bad idea, but there is no problem keeping old behaviour.
I don't see anything much wrong with sha1(bytea/text) - bytea.
There's no law that says it has to work exactly like md5()
On Aug 12, 2011, at 12:09 PM, Peter Eisentraut wrote:
I figure there might be warnings you haven't seen if you haven't been
building with bonjour, perl, openssl, pam, libxml, or ossp-uuid, so
I've attached the output.
We have a build farm member (smew) that covers all of that except
Hackers,
Given this script on 9.1beta3:
BEGIN;
CREATE EXTENSION plperl;
CREATE OR REPLACE FUNCTION wtf(
) RETURNS TEXT[] LANGUAGE plperl AS $$ return []; $$;
SELECT wtf() = '{}'::TEXT[];
ROLLBACK;
The output is:
BEGIN
CREATE EXTENSION
CREATE FUNCTION
On Aug 12, 2011, at 6:17 PM, Alex Hunsaker wrote:
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also adds some
additional comments)
Fix confirmed, thank you!
+1 to getting this committed before the next beta/RC.
David
On Aug 9, 2011, at 6:00 PM, Peter van Hardenberg wrote:
In conclusion, this is a serious operational concern for me and my team and I
will be personally dealing with fires caused by this for years to come
regardless of the outcome of this thread.
Do you have an interest in funding
On Aug 10, 2011, at 9:44 AM, Andrew Dunstan wrote:
After some experimentation, I found that, at least on my system, if LWP uses
Crypt::SSLeay for https requests then it sets an alarm handler, but if
instead it uses IO::Socket::SSL an alarm handler is not set. So the answer to
the OP's
On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
Mainly the options im thinking about are:
1) if anyone touches %SIG die
2) turn %SIG into a regular hash so people can set/play with %SIG, but
it has no real effect.
These would disable stuff like $SIG{__WARN__} and $SIG{__DIE__}, which would
On Aug 3, 2011, at 1:47 AM, Peter Geoghegan wrote:
So, there are 4 remaining warnings.
I haven't been paying attention to warnings, but FWIW 9.1beta3 has been
building with LLVM by default with Xcode 4. Both on Snow Leopard and on Lion I
saw something like this:
try=# select version();
On Aug 3, 2011, at 11:17 AM, Peter Eisentraut wrote:
Note that what you are using there is a GCC frontend with a LLVM
backend. (So I suppose you would get mostly GCC warnings.) Clang is a
new/different compiler frontend using the LLVM backend.
Yeah, not sure whether or not to tweak the
On Aug 3, 2011, at 11:28 AM, Grzegorz Jaskiewicz wrote:
export CC=clang
./configure
...
Thanks, I'll give that a try the next time I build (RC1 I guess).
David
On Jul 27, 2011, at 1:08 PM, Tom Lane wrote:
Yeah. If we're going to allow this then we should just have a concept
of a non-inherited constraint, full stop. This might just be a matter
of removing the error thrown in ATAddCheckConstraint, but I'd be worried
about whether pg_dump will handle
On Jul 15, 2011, at 9:41 AM, Tom Lane wrote:
Well, actually, that code flat out doesn't work, so whether relistemp is
available in 9.1 is the least of your problems. Consider what would
happen if two concurrent sessions did this with the same temp table
name.
Oh. Duh.
How about doing this
On Jul 21, 2011, at 2:39 PM, Jim Nasby wrote:
CREATE OR REPLACE FUNCTION is_timezone(
tz CITEXT
) RETURNS BOOLEAN LANGUAGE plpgsql STABLE AS $$
...
CREATE DOMAIN timezone AS CITEXT CHECK ( is_timezone( VALUE ) );
Storing giant globs of text with every timestamp field is really ugly.
On Jul 19, 2011, at 2:06 PM, Josh Berkus wrote:
I am strongly in favor of having a *timezone* data type and some system
whereby we can uniquely identify timezones in the Zic database.
CREATE OR REPLACE FUNCTION is_timezone(
tz CITEXT
) RETURNS BOOLEAN LANGUAGE plpgsql STABLE AS $$
BEGIN
On Jul 16, 2011, at 7:16 PM, Robert Haas wrote:
But what happens when and if we add global temporary tables? Now we
might very well decide to set the faux-relistemp to true for temporary
and global temporary tables (they do have temporary in the name,
after all!) and false for unlogged and
On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't forget to use the table name or alias in front of it... :-)
Oh, nice hack. How far back
On Jul 14, 2011, at 12:05 AM, Hiroshi Saito wrote:
Hi Thomas-san, Ralf-san.
I appreciate your great work.
Thanks!
CC to Postgres-ML.
Regards,
Hiroshi Saito
(2011/07/14 3:49), Thomas Lotterer wrote:
Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...
Ah,
On Jul 14, 2011, at 9:55 AM, Heikki Linnakangas wrote:
Far back. But you only need it in = 9.1. Older versions have the
pg_class.relistemp column anyway.
Yeah.
Not sure how this helps, though. If you modify pgTAP to install that
automatically in pgTAP when dealing with a new server
On Jul 14, 2011, at 12:19 PM, Tom Lane wrote:
Are they not testing our 9.1 betas?
There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major
On Jul 14, 2011, at 2:10 PM, Dave Page wrote:
Break compatibility is actually something that is important to us - it
forces us to fix obvious issues, and makes it much harder to
inadvertently miss important changes.
Agreed, but a deprecation cycle would be much appreciated.
David
--
Sent
On Jul 14, 2011, at 3:05 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are a ton of
things that change with each release, and all we do by putting in
hacks for backwards compatibility is add bloat that needs to be
maintained, and encourage vendors to be lazy.
I don't
On Jul 14, 2011, at 6:43 PM, Robert Haas wrote:
Is that all I need to do, or is there something else I should be aware of
with regard to unlogged tables?
Probably not, in this case. Just a thought: maybe you could rewrite the query
to check whether the namespace name starts with pg_temp.
On Jul 13, 2011, at 6:44 AM, Hiroshi Saito wrote:
Um, Although I have not caught up with this thread.
Ralf-san and the member of OSSP are maintaining OSSP continuously.
I think that a reaction can merely be obtained in the intervals of when busy.
Please do not need fast response.
I have
Hackers,
With regard to this change:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995
I'm wondering if it would be possible to restore the relistemp column to
pg_class, at least for backwards compatibility, so that apps that expected
On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
I'm wondering if it would be possible to restore the relistemp column
to pg_class, at least for backwards compatibility, so that apps that
expected it can continue to work on both 9.0 and 9.1. Even if it's
read-only somehow, and the same as
On Jul 13, 2011, at 12:38 PM, Alvaro Herrera wrote:
Well, that assumes people read the documention and don't just do \d.
Keeping cruft around over time makes the system more complex.
This seems a case where column synonyms would have been useful (as was
the procpid / pid change).
Well it
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 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
--
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 5:07 PM, Tom Lane wrote:
Curious considering that the machine is there (responds to ping), and
the ossp.org webserver works fine. Has anyone bugged the owner about
that?
I've sent him email and Twitter DMs, to no avail.
Best,
David
--
Sent via pgsql-hackers mailing
On Jul 12, 2011, at 5:06 PM, Josh Berkus wrote:
I'm okay with this, though given the fact that ftp.ossp.org has been down
for *months*, I'm inclined to think that we ought to include it in the
contrib distribution for easy linking.
What license is it under?
COPYRIGHT AND LICENSE
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
301 - 400 of 1565 matches
Mail list logo
