On Sun, Feb 7, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 7, 2010 at 3:37 PM, Josh Berkus j...@agliodbs.com wrote:
As between the two, I get the feeling that there is more interest in
writeable CTEs. But that impression might be wrong, since it's an
unscientific
On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
2. Add an extra lock to serialize writers to the queue, so that messages
are guaranteed to be added to the queue in commit order. As long as
fwiw, I think you're definitely on the right track. IMO, any scenario
where an
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying
On Sat, Feb 20, 2010 at 4:33 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
Hi,
I'm trying to figure out how difficult is this
What we need:
- a shared catalog
- an API for filling the catalog
- a scheduler daemon
- pg_dump support
A shared catalog
-
On Sat, Feb 20, 2010 at 8:06 PM, Joshua D. Drake j...@commandprompt.com wrote:
That doesn't mean it isn't a really good idea. It would be nice to have
a comprehensive job scheduling solution that allows me to continue
abstract away from external solutions and operating system dependencies.
On Mon, Feb 22, 2010 at 2:29 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Merlin Moncure escribió:
Like I noted above, what people want to schedule is going to be stored
procedures. Having both would virtually eliminate the need for
scripting outside the database, which is a pretty
On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still haven't seen a good reason for not using cron or Task Scheduler
or other standard tools.
*) provided and popular feature in higher end databases
*) the audience you cater to expects it
*) IMO, it should simply not be
On Mon, Mar 1, 2010 at 4:43 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure mmonc...@gmail.com wrote:
IMNSHO, an 'in core' scheduler would be useful. however, I think
before you tackle a scheduler, we need proper stored procedures. Our
existing
2010/3/5 François Pérou francois.pe...@free.fr:
= All non-aggregate fields must be present in the GROUP BY clause
http://drupal.org/node/30
My take is that this is never going to happen unless we are strictly
talking about cases where the non-aggregate fields can be
unambiguously
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
merlin
--
Sent via pgsql-hackers mailing list
On Tue, Mar 9, 2010 at 1:45 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
updated version, concat function doesn't use separator
btw...very cool stuff. I took a brief look at the sprintf
implementation. The main switch:
switch (pdesc.field_type)
It looks like format codes we choose not to
On Wed, Mar 10, 2010 at 7:50 AM, Andrew Dunstan and...@dunslane.net wrote:
2010/3/9 strk s...@keybit.net:
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By dynamic I mean that the field name
is a variable in the trigger context.
I've been told it's easy to
On Thu, Mar 11, 2010 at 11:24 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Merlin Moncure escribió:
(small aside: the other biggie would be able to push a composite type
in to an update statement...something like 'update foo set foo =
new'). This is really great...some variant
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
What's wrong with UPDATE foo SET (foo) = (NEW); ?
amen brother! :-)
I say though, since you can do:
SELECT foo FROM foo;
why not
UPDATE foo SET foo = new;?
merlin
--
Sent via pgsql-hackers mailing list
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(This will also be my main objection to letting hstore into core.
It has not solved the problem of handling real datatypes.)
Is this problem solvable then? Some variant of this question comes up
almost weekly. It just doesn't
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder if it could work to treat the result of a record-fieldname
operator as being of UNKNOWN type initially, and resolve its actual
type in the parser in the same way we do for undecorated literals
and parameters, to wit
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan and...@dunslane.net wrote:
Not quite, but close. We also need a nice way of querying for field names
(at least) at run time. I've seen that requested several times.
ok. just making sure we were on the same page. wasn't there a
technical objection
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already)
yeah...explicit cast should always do 'best effort'
The cost of looking up
On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing
On Tue, Mar 16, 2010 at 5:53 PM, Florian Pflug fgp.phlo@gmail.com wrote:
which returns the field named field from the record. The expected
field type is specified by providing a default value in defval of the
expected type. Since that argument's type is ANYELEMENT, just like the
return
On Tue, Apr 6, 2010 at 1:47 AM, Josh Berkus j...@agliodbs.com wrote:
Hackers,
Continuing the performance test:
DBD, like a number of monitoring systems, does pings on the database
which look like this:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the
On Tue, Apr 6, 2010 at 12:08 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
Any clue why this
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
it is little bit offtopic. Can we add info about assertation to
version() output?
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
On Tue, Apr 27, 2010 at 10:32 AM, Michael Tharp
g...@partiallystapled.com wrote:
On 04/27/2010 09:59 AM, Kevin Grittner wrote:
Under what circumstances would PostgreSQL
modify a file without changing the last modified timestamp or the
file size?
Do all OSes have sub-second precision mtimes?
On Tue, Apr 27, 2010 at 11:13 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Merlin Moncure mmonc...@gmail.com wrote:
The proposal only seems a win to me if a fair percentage of the
larger files don't change, which strikes me as a relatively low
level case to optimize for.
That's
On Fri, Apr 30, 2010 at 8:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 30, 2010 at 3:33 AM, Scott Bailey arta...@comcast.net wrote:
Proposal: Add an invalid flag to pg_class. Invalid objects would be ignored
when doing dependency checks for DDL statements. And an exception would
On Tue, May 4, 2010 at 10:05 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
and then string_to_array and array_to_string are orthogonal with NULL.
I like the behavior, but should it share the name with the 2 argument
version given the incompatibility? Maybe make a new function
On Thu, May 6, 2010 at 3:01 PM, Joseph Adams joeyadams3.14...@gmail.com wrote:
This isn't exactly a bug, but it could be considered unintuitive
behavior. Consider this:
by unintuitive you mean: 'explicitly defined in the SQL standard' :-).
I happen to agree with you but that's irrelevant. If
On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan and...@dunslane.net wrote:
And many places regard select * in anything other than throw-away queries
as bad practice anyway. I have seen people get bitten by it over and over
again, and I have worked at companies where it is explicitly forbidden in
On Wed, May 12, 2010 at 11:34 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
I would to repeatably update non indexed column of temp table. I
expected cheap operation, but it isn't true.
You're updating the row 10 times within a single
On Wed, May 12, 2010 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
You're updating the row 10 times within a single transaction. I
don't *think* HOT will reclaim a version of a row until the
transaction which completed it is done and no
On Mon, May 17, 2010 at 2:15 PM, Jim Nasby deci...@decibel.org wrote:
On May 6, 2010, at 4:29 PM, Merlin Moncure wrote:
On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan and...@dunslane.net wrote:
And many places regard select * in anything other than throw-away queries
as bad practice anyway. I
On Mon, May 17, 2010 at 2:15 PM, Jim Nasby deci...@decibel.org wrote:
On May 6, 2010, at 4:29 PM, Merlin Moncure wrote:
On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan and...@dunslane.net wrote:
And many places regard select * in anything other than throw-away queries
as bad practice anyway. I
On 3/29/07, Tom Lane [EMAIL PROTECTED] wrote:
As was pointed out awhile ago
http://archives.postgresql.org/pgsql-general/2007-02/msg00673.php
it's insecure to run a SECURITY DEFINER function with a search_path
setting that's under the control of someone who wishes to subvert
the function. Even
On 3/29/07, Stephen Frost [EMAIL PROTECTED] wrote:
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
fwiw, I think this is a great solution...because the default behavior
is preserved you get through without any extra guc settings (although
you may want to add one anyways).
I agree
[forwarded from -patches]
I noticed that when psql accepts input from stdin or -f (but not -c),
and timing is set to on in .psqlrc, timing results are printed out to
stdout even when -q (quiet) is passed in.
This may not be the perfect solution, but it fixes the problem (I'm
having problems
On 4/12/07, NikhilS [EMAIL PROTECTED] wrote:
Hi,
Shouldn't the final command below cause a 'column b does not exist error'?
create table update_test (a int, b int);
create table supdate_test(x int, y int);
insert into update_test values (20, 30);
insert into supdate_test values (40, 50);
On 5/11/07, Tom Lane [EMAIL PROTECTED] wrote:
BTW, in the array patch as just committed, I was able to get rid of the
I am testing this feature, no problem so far. It's fast, and works
exactly as advertised! Great work! (aiui, no domain arrays for 8.3?)
merlin
On 6/4/07, Wilhansen Li [EMAIL PROTECTED] wrote:
First of all, apologies if this was not meant to be a feedback/wishlist
mailing list.
Binary formats in libpq has been (probably) a long issue (refer to the
listings below) and I want to express my hope that the next
revision of PostgreSQL would
On 8/1/07, Rafael Azevedo [EMAIL PROTECTED] wrote:
Imagine that you have about 30 fields.
Ok, then your first SQL is done.
Now, you just have to add 10 more fields.
Its very easy to get lost. If we have this implementation, you could just
add
Field31 = 'text',
Field32 = 'text'
I have to
On 8/2/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET.
On 8/7/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum:
unpatched HOT
tps 3680
On 8/8/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 8/7/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum
On 8/8/07, Omar Bettin [EMAIL PROTECTED] wrote:
Hi,
I have installed postgresql to my client as a server for a progam
(libpq.dll/VCL based) that I wrote for them.
Every is working fine, but I noted some general slowness, compared with an
older database system (iAnywhere ADS)
due (I
On 8/9/07, Omar Bettin [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
AFAIK, the fastest possible way to get data off the server, skipping
all data and text processing is to write a SPI routine, and stream the
data out locally to the server. I am doing exactly this in a
particular
On 8/9/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Decibel! wrote:
This is also related to the desire to be able to restrict access to the
catalog tables. Doing so could potentially solve this problem; it
solves other issues (such as being able to see all the databases that
exist on a
On 8/14/07, ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum:
On 8/14/07, Bruce Momjian [EMAIL PROTECTED] wrote:
TODO item?
I would say yes...array_accum is virtually an essential function when
working with arrays and the suggested array_to_set (and it's built in
cousin, _pg_expand_array) really should not be built around
generate_series when a C function
Attached are some new functions that extend the libpq api to make
calling the parameterized interfaces easier, especially when making
binary calls. IMO, this fills one of the two big missing parts of the
libpq api when making binary database calls, the other being client
side handling of complex
On 8/17/07, Merlin Moncure [EMAIL PROTECTED] wrote:
Attached are some new functions that extend the libpq api to make
after sending the mail, we noticed some dead code that might be
confusing...in PQparamClear there was some legacy code referring to
'slab' which has no effect...ignore. Also
Attached is version 0.3 of the proposed PGparam extension to the libpq
API. I think we are wrapping up our changes in the short term and
will begin using our api for our internal projects. There were a lot
of changes and reorganizations, but the big features are that client
side geometry types
while playing with the binary transport of the money type we found
another bug. The following code segfaults the server on 8.3cvs:
select '3'::money * 2;
this was an accidental discovery by us but is the second serious bug
we found with the money type without looking very hard...probably
On 8/21/07, Magnus Hagander [EMAIL PROTECTED] wrote:
OTOH, if we do it as a compat package, we need to set a firm end-date on
it, so we don't have to maintain it forever. Given the issues always at
hand for doing such an upgrade, my vote is actually for ripping it out
completely and take the
I noticed that enums are not available to be queried as binary through
the protocol. Is this a known issue? Too late to fix for 8.3? This
is kind of a pain, because it forces any query that returns an enum to
return the entire result as text. afaik, enums are the only POD type
to behave this
On 8/30/07, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I noticed that enums are not available to be queried as binary through
the protocol.
What do you think the binary representation ought to be? Copying OIDs
seems pretty useless.
I'm on the fence
On 9/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Tom Lane wrote:
I've committed the HOT patch.
Thanks, much easier to work with it now that it's in.
I'd still like to think about whether we
can be smarter about when to invoke pruning, but that's a small enough
issue that the
On 9/21/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
pre hot:
run 1: 3617.641 ms
run 2: 5195.215 ms
run 3: 6760.449 ms
after vacuum:
run 1: 4171.362 ms
run 2: 5513.317 ms
run 3: 6884.125 ms
post hot:
run 1: Time: 7286.292 ms
run 2: Time: 7477.089 ms
On 9/21/07, Merlin Moncure [EMAIL PROTECTED] wrote:
Well, my first round of results are so far not showing the big gains I
saw with hot in some of the earlier patches...so far, it looks
approximately to be a wash although with the reduced need to vacuum.
let me correct myself here. I did some
On 9/24/07, Gregory Stark [EMAIL PROTECTED] wrote:
We previously discussed compressing the numeric data type for small values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
the weight and
On Thu, Aug 6, 2009 at 4:32 AM, Dimitri Fontainedfonta...@hi-media.com wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to
On Thu, Aug 6, 2009 at 11:11 AM, Andrew Dunstanand...@dunslane.net wrote:
Last night I needed to move a bunch of data from an OLTP database to an
archive database, and used dblink with a bunch of insert statements. Since I
was moving about 4m records this was distressingly but not surprisingly
On Thu, Aug 6, 2009 at 11:11 AM, Andrew Dunstanand...@dunslane.net wrote:
Last night I needed to move a bunch of data from an OLTP database to an
archive database, and used dblink with a bunch of insert statements. Since I
was moving about 4m records this was distressingly but not surprisingly
On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkusj...@agliodbs.com wrote:
All,
So really, the streaming replication patch should be called hot
standby, and the hot standby patch should be called read only slaves?
And *why* can't we call it log-based replication?
+1
*) it _is_ used to replicate
2009/8/12 Pierre Frédéric Caillaud li...@peufeu.com:
If you do as much damage to the I/O function API as the other patch
did, it will probably be rejected.
You mean, as the COPY patch in my previous message, or as another
patch ?
(I just search the archives and found one
On Tue, Sep 1, 2009 at 2:41 PM, Josh Berkusj...@agliodbs.com wrote:
All,
I've grown to adore the new \ef function editor.
It doesn't seem like it would be that difficult to add a view editor as
\ev. While editors would also be good for other objects, I don't think
we can do \et or \er etc.
On Tue, Sep 8, 2009 at 12:12 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Hi,
I'm seeking more powerful any pseudotypes. In particular, consider a
function
foo(type1, type2) returns type3
where type1 and type2 can be both any element type, but not necessarily
both of the same
On Fri, Sep 11, 2009 at 11:19 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think the main benefit of a sprintf type function for PostgreSQL is
in the formatting (setting
On Fri, Sep 11, 2009 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Is this really all that hard? I'm thinking it could be implemented by
using the real C sprintf underneath, passing one % specifier and its
corresponding parameter at a time,
On Fri, Sep 11, 2009 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
If you are going to use printf format codes, which is good and useful
being something of a standard, I'd call routine printf (not format)
and actually wrap vsnprintf. The format
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
How is it any worse than what people can already do? Anyone who isn't aware
of the dangers of SQL injection has already screwed themselves. You're
basically arguing that they would put a variable inside of quotes, but
On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan and...@dunslane.net wrote:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
On Fri, Sep 18, 2009 at 8:09 AM, Andrew Chernow a...@esilo.com wrote:
Hans-Juergen Schoenig -- PostgreSQL wrote:
Tom,
On behalf of the entire PostgreSQL team here in Austria I want to wish you
a happy birthday.
We hope that you fill be a vital part of PostgreSQL for many years to
come.
On Sat, Sep 19, 2009 at 8:23 PM, Andrew Dunstan and...@dunslane.net wrote:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a
On Fri, Sep 25, 2009 at 1:05 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Euler == Euler Taveira de Oliveira eu...@timbira.com writes:
Euler Ops... forgot to remove it from other test. It seems much
Euler better but far from the ideal. :( I've never taken a look at
Euler the
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas robertmh...@gmail.com wrote:
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
INSERT INTO big_table_2 ... this is going to suck pretty bad. I
Is the above form:
On Mon, Oct 12, 2009 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course the downside of changing it is that queries that worked fine
before might work differently (and much
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in
On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom has proposed some kind of odd special options syntax to get around
this, but I think that's unnecessary. So far on this thread, I haven't
seen anyone engineer an actual function exploit by using this setting; I
On Fri, Oct 23, 2009 at 11:07 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Any change here is *not* a bug fix, it is a change of clearly
documented and not-obviously-unreasonable behavior. We have to take
seriously the likelihood that it will break
On Mon, Oct 26, 2009 at 1:54 AM, Christophe Pettus x...@thebuild.com wrote:
Greetings,
I'd like to propose a potential patch, and wanted to get preliminary
feedback on it before I started looking into the design.
Summary: Add a string key space to the advisory lock functionality.
On Mon, Oct 26, 2009 at 11:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Kiswono Prayogo wrote:
plv8js is a procedural language add-on for PostgreSQL, which means you
can define Javascript functions that run inside a PostgreSQL server
using google V8 Engine.
anyone who want to contribute
On Mon, Oct 26, 2009 at 4:30 PM, Josh Berkus j...@agliodbs.com wrote:
Why aren't you satisfied with hashtext('foo') ?
Collisions, mostly.
Why even bother with a hash function when you can just have multiple
table pull from a shared sequence? AFAICT, this solves the OP's
problem with no
On Tue, Oct 27, 2009 at 12:43 PM, Josh Berkus j...@agliodbs.com wrote:
Merlin,
Why even bother with a hash function when you can just have multiple
table pull from a shared sequence? AFAICT, this solves the OP's
problem with no downsides (I used the approach with excellent results
in a
On Mon, Nov 2, 2009 at 6:00 AM, Ivo Raisr iv...@ivosh.net wrote:
Hi guys,
I hacked PostgreSQL 8.4.1 libpq and added a new function to specify
resultFormat for individual result columns.
Are you interested in a patch?
(http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says:
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE persons_type AS (name
On Wed, Nov 11, 2009 at 5:48 PM, A.M. age...@themactionfaction.com wrote:
At least with this new payload, I can set the payload to the transaction ID
and be certain that all the notifications I sent are processed (and in order
even!) but could you explain why the coalescing is still necessary?
On Thu, Nov 12, 2009 at 8:25 AM, Andrew Chernow a...@esilo.com wrote:
2. The payload parameter is optional. A notifying client can either call
NOTIFY foo; or NOTIFY foo 'payload';. The length of the payload is
currently limited to 128 characters... Not sure if we should allow
longer
payload
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
Yes. Particularly those complaining that they want to have
On Thu, Nov 12, 2009 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not
On Thu, Nov 12, 2009 at 11:40 AM, Merlin Moncure mmonc...@gmail.com wrote:
I'm sorry, the 128 character limit is simply lame (other than for
unsolvable implementation/performance complexity which I doubt is the
case here), and if that constraint is put in by the implementation,
than
On Fri, Nov 13, 2009 at 5:35 AM, Greg Stark gsst...@mit.edu wrote:
On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas robertmh...@gmail.com wrote:
I agree. We frequently reject features on the basis that someone
might do something stupid with them. It's lame and counterproductive,
and we should
On Fri, Nov 13, 2009 at 10:00 AM, Andrew Chernow a...@esilo.com wrote:
I think the original OP was close. The structure can still be fixed length
but maybe we can bump it to 8k (BLCKSZ)?
The problem with this (which I basically agree with) is that this will
greatly increase the size of the
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This might look neat but I don't think it's actually useful for any
production application. We'd need to find some way of expressing it
that allows caching of the expression plans. But really I think the
entire approach is
On Fri, Nov 13, 2009 at 11:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(By the way, has anyone yet tried to
compare the speed of this implementation to the old code?)
I quickly hacked pgbench to take a custom script on connection (for
listen), and make pgbench'd 'notify x'; with all clients doing
On Thu, Apr 3, 2008 at 2:43 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Some sort of \x auto? Sounds interesting ...
Yep.
Having \df+ go to \x automatically sounds like a really great idea :)
you can get pretty good
On Thu, Apr 3, 2008 at 4:08 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 03:43:50PM -0400, Merlin Moncure wrote:
On Thu, Apr 3, 2008 at 2:43 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Some sort of \x
On Tue, Apr 8, 2008 at 12:59 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Sorry for the bad news. I think we all hoped that enough interest would
be generated for this to be accepted.
I think that's really unfortunate. Personally, I think that anyone
who did any amount of C coding against
On Tue, Apr 8, 2008 at 1:51 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state
On Tue, Apr 8, 2008 at 2:49 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
401 - 500 of 1941 matches
Mail list logo
