On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
I've appended the POD documentation and attached the (rough but working)
test script.
I plan to release the module to CPAN in the next week or so.
I'd greatly appreciate any feedback.
I like the idea overall, and anything that can simplify
On Feb 13, 2010, at 6:32 AM, Andrew Dunstan wrote:
My feeling is if we provide something we are responsible for it, documented
or not. Undocumented features with security implications raise big red flags
in my head. Maybe the difference in perspective comes from working on a
database as
On Feb 13, 2010, at 2:46 PM, Andrew Dunstan wrote:
I'm confused. Doesn't on_plperl_init already give us this? Isn't any of the
stuff loaded by that GUC then available from inside the PLPerl Safe
compartment?
No (and if it does it's a bug). Try it and see.
Then what's the point of it?
On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote:
To perform initialisation, such as setting a value in %_SHARED.
Hrm. Well, as a DBA, I'd *really* like to be able to make some things available
from within a Safe container, such as Devel::NYTProf::PgPLPerl or the
PostgreSQL::PLPerl::Call
On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
The text is about 180Kb. PostgreSQL takes ~40 seconds without the
patch, ~36 seconds with it, to extract the match from it. Perl takes
0.016 seconds.
Obviously we need to support Perl regular expressions in core. Not PCRE, but
Perl. ;-P
On Feb 8, 2010, at 9:34 AM, Josh Berkus wrote:
Eh? Previously we allowed code to go in with documentation to be
written after feature freeze. Is this no longer acceptable?
My $0.0201115:
I think you need to use a NUMERIC type there, as some calculation has lost
precision in the float.
On Feb 7, 2010, at 12:35 PM, Josh Berkus wrote:
I've always thought this feature was misnamed and nothing has happened
to change my mind, but it's not clear whether I'm in the majority.
I'm afraid force of habit is more powerful than correctness on this one.
It's going to be HS/SR whether
On Feb 3, 2010, at 6:16 PM, Robert Haas wrote:
Any web framework that interpolates user supplied values into SQL rather
than using placeholders is broken from the get go, IMNSHO. I'm not saying
that there aren't reasons to hold up moving to SCS, but this isn't one of
them.
That seems more
On Feb 3, 2010, at 9:21 AM, Alex Hunsaker wrote:
plperl.on_init - run on interpreter creation
plperl.on_plperl_init - run when then specialized for plperl
plperl.on_plperlu_init - run when then specialized for plperlu
Hrm, I think I agree with Tom that we should not
On Feb 3, 2010, at 11:04 AM, Tom Lane wrote:
What I was actually wondering about, however, is the extent to which
the semantics of Perl code could be changed from an on_init hook ---
is there any equivalent of changing search_path or otherwise creating
trojan-horse code that might be executed
On Feb 1, 2010, at 10:53 AM, Tom Lane wrote:
The first thought that comes to mind is plpythonng, following a
tradition established by the tcl client rewrite among others ... but
that double n doesn't read very well.
And without it, you have a thong. Who's going to wear that?
Best,
David
--
On Jan 29, 2010, at 10:43 AM, Robert Haas wrote:
I haven't even looked at this code - I sort of assumed Itagaki was
handling this one. But it might be good to make sure that the docs
have been read through by a native English speaker prior to commit...
I did and revised them slightly. There
On Jan 29, 2010, at 10:46 AM, Robert Haas wrote:
I did and revised them slightly. There isn't much, just a brief comment in
the table of aggregate functions. The documentation for all the functions on
that page could use a little love, frankly.
Want to take a short at it?
ENOTUITS! /me
On Jan 29, 2010, at 11:51 AM, Bruce Momjian wrote:
With the release of Postgres 9.0, should we consider changing the
default for 'standard_conforming_strings'?
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jan 28, 2010, at 9:29 AM, Marko Tiikkaja wrote:
Someone might have a perfectly good use case for using different
delimiters. I don't think it's a good idea to be artificially limiting
what you can and can't do.
+1
David
--
Sent via pgsql-hackers mailing list
On Jan 28, 2010, at 12:01 PM, Tim Bunce wrote:
Once the previous patch lands I'll post an update to this patch with
those changes applied.
Ds the Add on_perl_init and proper destruction to plperl patch the one you're
waiting on, then?
Best,
David, who loses track of these things
--
Sent
On Jan 27, 2010, at 9:08 AM, Tom Lane wrote:
This is exactly the claim that I have zero confidence in. Quite
frankly, the problem with Perl as an extension language is that Perl was
never designed to be a subsystem: it feels free to mess around with the
entire state of the process. We've
On Jan 27, 2010, at 10:08 AM, Tom Lane wrote:
Two examples that I can find in a quick review of our CVS history: perl
stomping on the process's setlocale state, and perl stomping on the
stdio state (Windows only).
Are there links to those commits?
Thanks,
David
--
Sent via pgsql-hackers
On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
Okay. I could change the callback code to ignore calls if
proc_exit_inprogress is false. So an abnormal shutdown via exit()
wouldn't involve plperl at all. (Alternatively I could use use
on_proc_exit() instead of atexit() to register the
On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
What exactly do we mean by system-level actions? I mean, END blocks
can execute arbitrary code
Yeah. In Perl. What part of Perl can access the backend systems without SPI?
And that it couldn't do at any other point in runtime?
Best,
David
On Jan 27, 2010, at 2:38 PM, Tom Lane wrote:
These proposals sound reasonable to me too, but is everything an
appropriate target name, or is there some other/better convention?
Oooh, more bike-shedding.
make theworld
make toutlemonde
make myday
make lovenotwar
Best,
David
On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:
You still aren't letting go of the notion that Perl could only affect
the rest of the backend via SPI. The point I'm trying to impress on you
is that there are any number of other possible pathways, and that Perl's
historical assumption that it
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
I don't have to read any further than the place where it says doesn't
work if you call both plperl and plperlu to realize that that's quite
false. Maybe we have different definitions of what a software
interaction is...
I think that dates from
On Jan 27, 2010, at 4:10 PM, Tom Lane wrote:
Absolutely. The difference here is in who is going to be expected to
try to deal with any problems. When somebody says if I do this in
plperlu, my database crashes! Postgres sux! it's not going to help to
say that's a Perl bug, even if an
On Jan 27, 2010, at 4:15 PM, Tom Lane wrote:
Is that not the case with plperlu already?
Sure. Which is why I'm resisting expanding our exposure to it
I don't understand how it's expanding core's exposure to it.
Best,
David
--
Sent via pgsql-hackers mailing list
On Jan 27, 2010, at 4:33 PM, Tom Lane wrote:
[ shrug...] I see little point in repeating myself yet again.
It's obvious that the people who want this are entirely willing
to adopt a Pollyanna-ishly optimistic view about its potential
to cause serious problems that we may or may not be able
On Jan 27, 2010, at 7:58 AM, Pavel Stehule wrote:
with actualised oids
Thanks. Looks good, modulo my preference for concat_agg(). I'll mark it ready
for committer.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
should return 'A+B*C' rather than 'A,B,C'.
Ooh, nice.
* Can
On Jan 25, 2010, at 23:14, Pavel Stehule pavel.steh...@gmail.com
wrote:
why is concat_agg better than listagg ?
Because it's an aggregate that cocatenates values. It's not an
aggregate that lists things. I also like concat_agg better than
string_agg because it's not limited to acting on
On Jan 26, 2010, at 4:03, Peter Eisentraut pete...@gmx.net wrote:
What else can it act on?
Any data type, since they all can be converted to text. Integers would
be a common choice.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Jan 26, 2010, at 9:36 AM, Tom Lane wrote:
But what it *produces* is a string. For comparison, the
SQL-standard-specified array_agg produces arrays, but what it
acts on isn't an array.
Meh. This is all just bike-shedding. I'm fine with string_agg(), though in
truth none of the names has
On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:
actualised patch - the name is string_agg
All looks fine except I'm getting this error during initdb:
creating template1 database in /usr/local/pgsql-devel/data/base/1 ... FATAL:
could not create unique index pg_proc_oid_index
DETAIL: Key
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
concat_agg().
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
I am not happy, I thing so we do bigger chaos then it is. But it
hasn't progress. So I agree with name string_agg. In this case isn't a
problem rename this function if somebody would.
Could you not use CREATE AGGREGATE to create an alias named
On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
can I help with it, please. My English is terrible.
Yes, I added a bit in the patch I submitted.
array user functions are used more time in pg core. The complexity of
array functions are much higher, so I don't think we need special
file.
On Jan 24, 2010, at 2:04 PM, Tom Lane wrote:
I don't see any strong argument for having a default for CREATE
FUNCTION. The original argument for having a GUC for DO was that
plpgsql wasn't built in; now that it is, I think a case could
be made for dropping default_do_language in favor of a
On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
$name =~ s/::|'/_/g; # avoid package delimiters
+ $name =~ s/'/\'/g;
Looks to me like ' is already handled in the line above the one you added, no?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Jan 23, 2010, at 3:25 AM, Greg Stark wrote:
Actually the original promounciation was mee-ess-cue-ell, My is
monty's daughter's name and is pronounced like that. People generally
pronounced it my though so they just made that the official
pronounciation -- but they still don't approve of
On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
Well no, i suppose we could fix that via:
$name =~ s/[:|']/_/g;
Im betting that was the intent.
Doubtful. In Perl, the package separator is either `::` or `'` (for hysterical
reasons). So the original code was replacing any package
On Jan 23, 2010, at 1:22 PM, Magnus Hagander wrote:
FYI, the figures for the past month are:
1.postgresql 45,579 10.91%
2.postgres16,225 3.88%
3.postgre 4,901 1.17%
4.postgresql download 4,590 1.10%
5.
Pavel,
My review of your listagg patch.
Submission Review
-
* The diff is a context diff and applies cleanly to HEAD (with just two hunks
offset by 2 lines each).
* There is documentation, though I'm not sure it needs to be mentioned in the
string functions documentation. No
On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
their name? I think it is the opposite. SQL in the name almost grants
legitimacy to them as products. Dropping the SQL has the potential to
increase confusion. What is a
On Jan 21, 2010, at 9:19 AM, Robert Haas wrote:
As far as I can see, there is absolutely zero reason to care about
whether the product is called Postgres or PostgreSQL.
How about simply Post? Or just SQL? ;-P
If it were
called WeGrindUpTheBonesOfSmallChildrenSQL, maybe a change would be
On Jan 19, 2010, at 9:26 PM, Andrew Dunstan wrote:
The first thing I think we need to do is move the GUC processing code out of
_PG_init() and into plperl_init_interp(), protected by a flag to make sure
it's only called successfully once. I'm trying to work out a neat way to put
the value
On Jan 21, 2010, at 9:46 AM, David Christensen wrote:
It uses the same quoting mechanism as regclass, and I've tested against some
odd schema names such as fooschema; I updated the docs as I was able, but
am not familiar enough with the regression tests to add those yet. I hope to
address
On Jan 21, 2010, at 9:57 AM, Tom Lane wrote:
Schema names of what? It sounds to me like you're failing to use the
existing regfoo types in appropriate places ...
The names of schemas in which to find functions, tables, views, triggers, etc.
etc. I have lots of stuff like this:
On Jan 21, 2010, at 10:06 AM, Tom Lane wrote:
Well, without a context that explains *why* you're doing that, it's hard
to consider what a better solution would look like. Personally I
usually prefer solutions involving WHERE oid = 'foo.bar'::regclass,
because that scales easily to either
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going to apply
at the end of the commitfest?
I generally agree that we need to have a bit of wiggle room at this stage -
small and non-controversial items can be allowed to
On Jan 21, 2010, at 4:55 PM, Andrew Dunstan wrote:
*shrug* I don't have a strong opinion about it, and it's pretty easy to
change, if there's a consensus we should. I have certainly found over the
years that perl warnings from some modules can be annoyingly verbose, which
is probably why
On Jan 19, 2010, at 11:10 AM, Tim Bunce wrote:
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Start reviewing other patches. An active/helpful patch submitter gets more love.
Best,
David
--
Sent via pgsql-hackers mailing list
On Jan 19, 2010, at 12:58 PM, Stefan Kaltenbrunner wrote:
well providing a hint that one should use different command will only lead to
the path uhm why not make it work as well
I don't think so. People know it's a different database. They'd be thrilled
just to get the hint. I think it's a
On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
I thought Magnus had a really good point: covering these four cases will
probably be enough to teach newbies to look at psql's backslash
commands. And once they absorb that, we're over a big hump.
+1
On Jan 19, 2010, at 1:57 PM, Devrim GÜNDÜZ
On Jan 17, 2010, at 3:47 PM, Tom Lane wrote:
create type y as (c char, n int);
select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
select ('a', NULL) = ('a', NULL); -- NULL
I would expect those to evaluate to the same thing.
The latter gets simplified to ('a' = 'a') AND (NULL = NULL).
On Jan 15, 2010, at 9:37 AM, Robert Haas wrote:
But I'm still wondering why this isn't replication.
I was wondering the same thing. ISTM that the docs could reference third-party
replication solutions, too (or a wiki page listing them, since they'll change
often).
Anyway, I think Heikki's
On Jan 14, 2010, at 8:07 AM, Tim Bunce wrote:
- Stored procedure subs are now given names.
The names are not visible in ordinary use, but they make
tools like Devel::NYTProf and Devel::Cover _much_ more useful.
Wasn't this in the previous patch, too?
Best,
David
--
Sent via
On Jan 10, 2010, at 11:17 AM, Robert Haas wrote:
It's nicer to write:
plperl.on_perl_init='strict,warnings,LDAP,HTML::Parser,Archive::Zip'
rather than:
plperl.on_perl_init='use strict;use warnings;use LDAP;use
HTML::Parser;use Archive::Zip;'
Well, no, because sometimes I just want to
On Jan 8, 2010, at 1:35 AM, Dave Page wrote:
I am saying that if the design won't ever work without requiring
painful dependency installation that users will likely not want to
bother with, then it is fundamentally broken. Better to write one
system that can _eventually_ work everywhere, than
On Jan 8, 2010, at 1:02 AM, Dimitri Fontaine wrote:
Now, I'll second Greg Smith and Tom here, in that I think we need to run
the last commitfest as usual, knowing that the outcome of the commitfest
for any given patch is not it made it but we reviewed it. It's still
right for the project to
On Jan 8, 2010, at 9:24 AM, Dave Page wrote:
If that is the goal of your project then I withdraw my previous
comments, which were written on the belief that you were proposing a
generic distribution/build/installation system for PostgreSQL users.
It is a generic distribution and installation
On Jan 8, 2010, at 9:38 AM, Magnus Hagander wrote:
Is there a particular reason not to use the existing mirroring network
to distribute the files? If not, then I suggest using them should be
part of the design.
No, as long as PAUS can drop uploaded distributions onto the master FTP server,
On Jan 8, 2010, at 9:59 AM, Dave Page wrote:
Either can be arranged. For StackBuilder, we created a pgFoundry
project, so files can just be uploaded there by authorised users, from
where they get replicated back onto the mirror network.
Which leads us neatly back to the GForge URL thread
On Jan 8, 2010, at 10:08 AM, Magnus Hagander wrote:
That, or implement that send me to a random mirror feature. Or
maybe the send me to a random close mirror if available, or a random
global if not feature. :-)
Either way, there's definitely room for some improvement there, but
let's
On Jan 8, 2010, at 7:01 AM, Tim Bunce wrote:
I didn't get any significant feedback from the earlier draft so here's
the finished 'feature patch 1' for plperl. (This builds on my earlier
plperl refactoring patch, and the follow-on ppport.h patch.)
Significant changes from the first draft:
On Jan 6, 2010, at 6:26 PM, Tom Lane wrote:
We have not yet fully accepted the notion that you must have Perl to
build (and, in fact, I am right now trying to verify that you don't).
I don't think that requiring Perl to test is going to fly.
I believe that the build farm already requires
On Jan 6, 2010, at 6:31 PM, Kevin Grittner wrote:
As far as I've been able to determine so far, to call psql in a
relatively portable way would require something like this:
http://perldoc.perl.org/perlfork.html
Here's an example using IPC::Open3:
#!/usr/local/bin/perl -w
use
On Jan 7, 2010, at 9:08 AM, Tom Lane wrote:
Right, but to my mind building from a tarball needs to include the
ability to run the regression tests on what you built. So injecting
Perl into that is moving the goalposts on build requirements.
In that case, there's nothing for it except
On Jan 7, 2010, at 9:19 AM, Tom Lane wrote:
In that case, there's nothing for it except concurrent psql.
Unless we are prepared to define concurrency testing as something
separate from the basic regression tests. Which is kind of annoying but
perhaps less so than the alternatives. It
Hackers,
I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
I've tried to closely follow the [CPAN philosophy][] to come up with a plan
that requires a minimum-work implementation that builds on the existing
PostgreSQL tools and the examples of the [CPAN][] and
On Jan 7, 2010, at 12:10 PM, Heikki Linnakangas wrote:
But FWIW I have dedicated today and tomorrow for SR, and plan to
dedicate 2-3 days next week as well.
Should we then await what you determine over the next week?
Best,
David
--
Sent via pgsql-hackers mailing list
On Jan 7, 2010, at 12:36 PM, Dave Page wrote:
Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days seems
incredibly short sighted, and liable to lead to an endless stream of
'why doesn't this work' questions. It also does
On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine. For Windows
binaries are required.
I would love to follow what Strawberry Perl has done to solve this problem. In
2.0.
On Jan 7, 2010, at 1:59 PM, Joshua D. Drake wrote:
So +1 on Wheeler's idea.
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 Jan 7, 2010, at 2:11 PM, Peter Eisentraut wrote:
You might want to clarify in your prose what an extension is. I
suspect I know what you mean, but perhaps not everyone does.
Good suggestion, thanks. How about this in the FAQ?
* WTF is an extension?
An extension is a piece of software
On Jan 7, 2010, at 2:23 PM, Dimitri Fontaine wrote:
Maybe with a link to:
http://www.postgresql.org/docs/8.4/static/extend.html
Good call, thanks.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jan 6, 2010, at 11:27 AM, Andrew Dunstan wrote:
That's a case of out of date docco more than anything else, AFAIK. It's been
there at least since 5.6.2 (which is the earliest source I have on hand).
Which likely also means 5.6.1 and quite possibly 5.6.0. I don't recommend
anything earlier
On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
One of the things on my to-do list for today is to make configure reject
Perl versions less than $TBD. I thought we had agreed a week or so back
that 5.8 was the lowest safe version because of utf8 and other
considerations.
+1, and 5.8.3 at a
On Jan 6, 2010, at 1:52 PM, Kevin Grittner wrote:
Last I heard, Andrew was willing to require Test::More for
testing, so that a Perl script could handle multiple psql
connections (perhaps forked) and output test results based on
them. But he wasn't as interested in requiring DBI and DBD::Pg,
On Jan 6, 2010, at 2:08 PM, Peter Eisentraut wrote:
Then I don't see much of a point in using Perl. You might as well fire
up a few psqls from a shell script
If you're more comfortable with shell, then yes. Although then it won't run on
Windows, will it?
Best,
David
--
Sent via
On Jan 6, 2010, at 3:31 PM, Tim Bunce wrote:
For 8.5 I don't think I'll even attempt direct inter-plperl-calls.
I'll just do a nicely-sugared wrapper around spi_exec_prepared().
Either via import, as I outlined earlier, or Garick Hamlin's suggestion
of attributes - which is certainly worth
On Jan 6, 2010, at 5:46 PM, Tom Lane wrote:
I went with 5.8 as the cutoff, for a couple of reasons: we're not in
the business of telling people they ought to be up-to-date, but only of
rejecting versions that demonstrably fail badly; and I found out that
older versions of awk are not
On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
of spi_* calls. Umm. I thought performance was a major driving factor.
Sounds like you're more keen on syntactic sugar.
I'm saying do both. Make the cached version the one that
On Jan 4, 2010, at 3:29 PM, Peter Eisentraut wrote:
If you're not deep into Perl, perhaps ignore the Test::More comment for
the moment and just use DBI to connect to several database sessions,
execute your queries and check if the results are what you want. Once
you have gotten somewhere
On Jan 4, 2010, at 8:18 PM, Robert Haas wrote:
Is this something you are planning to work on for the 2010-01-15
CommitFest? If not, I think we should go ahead and mark the patch
which was the original subject of this thread Returned with
Feedback, as it does not seem to make sense to add it
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
extract a value, or set of values, from JSON
On Jan 1, 2010, at 6:01 PM, Kevin Grittner wrote:
It's very soon going to be critical that I be able to test particular
interleavings of statements in particular concurrent transaction sets
to be able to make meaningful progress on the serializable
transaction work. It would be wonderful if
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds right.
OK, but hstores are flat, unlike JSON. We need some way to
On Jan 3, 2010, at 11:54 AM, Andrew Dunstan wrote:
There are two issues with this patch. First, how far if at all should it be
backpatched? All the way, or 8.3, where we tightened the encoding rules, or
not at all?
8.3 seems reasonable.
Second, It produces errors like this:
andrew=#
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT ('{foo:{bar:[a,b,c]}}' - '[foo][1]')::text;
1
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any interesting
operators doesn't sound useless to me. The features I would like to get
out of it are input
On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
That handles the arity of the calls and invokes the right SP, bypassing
SQL if the SP is already loaded.
Nice.
That much works currently. Behind the scenes, when a stored procedure is
loaded into plperl the code ref for the perl sub is stored in
Fellow Hackers,
Given this SQL:
BEGIN;
CREATE ROLE foo WITH NOLOGIN;
CREATE ROLE foo_bar WITH LOGIN PASSWORD '***' INHERIT IN ROLE foo;
CREATE ROLE foo_baz WITH LOGIN PASSWORD '***' INHERIT IN ROLE foo;
CREATE ROLE foo_yow WITH LOGIN PASSWORD '***' INHERIT
IN ROLE
On Dec 31, 2009, at 3:41 PM, Tom Lane wrote:
My question is: why is the group membership of the foo_bar, foo_baz,
and foo_yow roles not reflected in pg_group?
Per the fine manual:
The view pg_group exists for backwards compatibility: it emulates a
catalog that existed in PostgreSQL
On Dec 29, 2009, at 6:14 PM, Robert Haas wrote:
I've been mulling this over and I think this is a pretty good idea.
If we could get it done in time for 8.5, we could actually change the
output type of EXPLAIN (FORMAT JSON) to the new type. If not, I'm
inclined to say that we should postpone
On Dec 30, 2009, at 9:53 AM, Robert Haas wrote:
It looks like they are all very permissive, though I wonder what the
legal effect of a license clause that the software be used for Good
and not Evil might be.
Yeah, that might be too restrictive, given that PostgreSQL is used by
government
On Dec 30, 2009, at 4:17 PM, Robert Haas wrote:
That much works currently. Behind the scenes, when a stored procedure is
loaded into plperl the code ref for the perl sub is stored in a cache.
Effectively just
$cache{$name}[$nargs] = $coderef;
That doesn't seem like enough to guarantee
On Dec 24, 2009, at 4:14 PM, Andrew Dunstan wrote:
2) How far is normalization support in PG? When I checked a long time
ago, there was no such support. Now that the SQL standard mandates a
NORMALIZE function that may have changed. Any updates?
Creating such a function shouldn't be
On Dec 21, 2009, at 9:04 PM, Andrew Dunstan wrote:
I cannot reproduce this. I tested with perl 5.10.1 which is the latest
reported stable release at http://www.cpan.org/src/README.html, on an 8.4.2
UTF8 database, and with the same Safe and Encode module versions as above.
I've replicated
On Dec 22, 2009, at 11:02 AM, Simon Riggs wrote:
I've clearly been working too hard and will retire for some rest (even
though that is not listed as a task on the Wiki).
Someone add it!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Dec 22, 2009, at 7:31 PM, Tom Lane wrote:
Wait a minute. I must have been looking at the wrong keyword list
--- ON already is reserved. The problem is exactly that it can't
tell whether CREATE INDEX CONCURRENTLY ON ... means to default the
index name or to create an index named
On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote:
Given the above three things it seems like we could define 5.8.1 as the
minimum required version.
I'd be delighted with that.
+1
BTW Tim, have you tested with 5.11 yet?
Best,
David
--
Sent via pgsql-hackers mailing list
901 - 1000 of 1565 matches
Mail list logo
