Joe and all,
The below listed tarball is out of date at this point, but I have updated
code laying around if someone really wanted it:
http://www.joeconway.com/sessfunc.tar.gz
I've used variations of this over the years on several projects.
is someone able and willing to provide this
2008/6/1 Harald Armin Massa [EMAIL PROTECTED]:
Joe and all,
The below listed tarball is out of date at this point, but I have updated
code laying around if someone really wanted it:
http://www.joeconway.com/sessfunc.tar.gz
I've used variations of this over the years on several projects.
Hello
I found following bug - using explain in stored procedures like:
CREATE OR REPLACE FUNCTION test(int)
RETURNS void AS $$
DECLARE s varchar;
BEGIN
FOR s IN EXECUTE 'EXPLAIN SELECT * FROM o WHERE a = $1+1' USING $1 LOOP
RAISE NOTICE '%', s;
END LOOP;
END; $$
LANGUAGE plpgsql;
Tom Lane [EMAIL PROTECTED] writes:
Jeff Davis [EMAIL PROTECTED] writes:
The objections to synchronized scans for VACUUM as listed in that thread
(summary):
2. vacuum takes breaks from the scan to clean up the indexes when it
runs out of maintenance_work_mem.
2. There have been suggestions
Gregory Stark [EMAIL PROTECTED] writes:
It will certainly not solve the problem. What it will do is mean that
the breaks are further apart and longer, which seems to me to make the
conflict with syncscan behavior worse not better.
How would it make them longer? They still have the same
Pavel Stehule [EMAIL PROTECTED] writes:
I found following bug - using explain in stored procedures like:
...
produce wrong result. Real plan is correct, etc variables are
substituted. Bud this explain show variables.
This seems to be correctable with a one-line patch: make SPI_cursor_open
set
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
This seems to be correctable with a one-line patch: make SPI_cursor_open
set the CONST flag on parameters it puts into the portal (attached).
I'm not entirely sure if it's a good idea or not --- comments?
We can do
2008/6/1 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
This seems to be correctable with a one-line patch: make SPI_cursor_open
set the CONST flag on parameters it puts into the portal (attached).
I'm not entirely sure if it's a good
Hi Merlin,
My point here is that with reasonably small extensions to the core you can
build products that are a lot better than SLONY. Triggers do not cover DDL,
among other issues, and it's debatable whether they are the best way to
implement quorum policies like Google's semi-synchronous
hello
2008/6/1 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I found following bug - using explain in stored procedures like:
...
produce wrong result. Real plan is correct, etc variables are
substituted. Bud this explain show variables.
This seems to be correctable
Gregory Stark wrote:
I think we do a pretty good job of this already. Witness things like
effective_cache_size -- imagine if this were nested_loop_cache_hit_rate for
example, good luck figuring out what to set it to.
I think either of these are fine if we describe how to measure
them.
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
What do you think a less invasive patch would be, anyway? I don't
buy that, say, having SPI_cursor_open_with_args set the flag but
SPI_cursor_open not do so is any safer. There is no difference between
the two as
2008/6/1 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
What do you think a less invasive patch would be, anyway? I don't
buy that, say, having SPI_cursor_open_with_args set the flag but
SPI_cursor_open not do so is any safer. There
On Sun, Jun 1, 2008 at 11:58 AM, Robert Hodges
[EMAIL PROTECTED] wrote:
Hi Merlin,
My point here is that with reasonably small extensions to the core you can
build products that are a lot better than SLONY. Triggers do not cover
DDL, among other issues, and it's debatable whether they are
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
This argument seems entirely bogus. How are they any more constant
than in the other case? The value isn't going to change for the life
of the portal in either case.
this is true Tom, but problem is in EXPLAIN. I
Merlin Moncure [EMAIL PROTECTED] writes:
On Sun, Jun 1, 2008 at 11:58 AM, Robert Hodges
[EMAIL PROTECTED] wrote:
My point here is that with reasonably small extensions to the core you can
build products that are a lot better than SLONY.
These issues are much discussed and well understood.
On Thu, May 29, 2008 at 4:12 PM, Tom Lane [EMAIL PROTECTED] wrote:
The Postgres core team met at PGCon to discuss a few issues, the largest
of which is the need for simple, built-in replication for PostgreSQL.
[...]
We believe that the most appropriate base technology for this is
1 probably
Hello
After some days I thing, so idea of local types is wrong. Maybe we can
register output types for or SRF functions (maybe only for table
functions), but this mechanism is redundant to explicit custom types.
Local functions types are nice, they allows better compile time check,
but they are
Xin Wang napsal(a):
Hi,
I don't know where I can find the doxyfile which generate
doxygen.postgresql.org web site. I found that when reading code the
doxygen source code is quite helpful. However, I want to generate an
off-line copy of doxygen docs myself, but I can't find the doxyfile in
2008/6/1 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/6/1 Tom Lane [EMAIL PROTECTED]:
This argument seems entirely bogus. How are they any more constant
than in the other case? The value isn't going to change for the life
of the portal in either case.
this is
David Fetter wrote:
This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
Marko Kreen wrote:
There is this tiny matter of replicating schema changes asynchronously,
but I suspect nobody actually cares. Few random points about that:
I'm not sure I follow you - the Sybase 'warm standby' replication of
everything is really
useful for business continuity. The
Aidan Van Dyk wrote:
The whole single-threaded WAL replay problem is going to rear it's ugly
head here too, and mean that a slave *won't* be able to keep up with a
busy master if it's actually trying to apply all the changes in
real-time.
Is there a reason to commit at the same points that the
On Thu, 2008-05-29 at 13:37 -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
The only question I have is... what does this give us that PITR
doesn't give us?
It looks like a wrapper for PITR to me, so the gain
On Fri, 2008-05-30 at 15:16 -0400, Robert Treat wrote:
On Friday 30 May 2008 01:10:20 Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Andrew Dunstan wrote:
We already have include directives, and have had since 8.2.
Heh, thanks - which proves how useless they are to me. :)
Joshua Drake wrote:
I kind of agree with this but actually think we should have the bare
minimum
Tom Lane wrote:
Tommy Gildseth [EMAIL PROTECTED] writes:
One obvious disadvantage of this approach, is that I need to connect and
disconnect in every function. A possible solution to this, would be
having a function f.ex dblink_exists('connection_name') that returns
true/false depending on
Howdy,
I'm sure I'm just showing off my ignorance here, but here goes…
I really need case-insensitive string comparison in my database.
Ideally there'd be a nice ITEXT data type (and friends, ichar,
ivarchar, etc.). But of course there isn't, and for years I've just
used LOWER() on
David E. Wheeler [EMAIL PROTECTED] writes:
I really need case-insensitive string comparison in my database.
Okay ... according to whose locale?
Ideally there'd be a nice ITEXT data type (and friends, ichar,
ivarchar, etc.). But of course there isn't, and for years I've just
used
David E. Wheeler napsal(a):
Howdy,
I'm sure I'm just showing off my ignorance here, but here goes…
I really need case-insensitive string comparison in my database.
Collation per database level should be help you. It is now under development and
I hope it will be part of 8.4. You can see
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Joshua Drake wrote:
I kind of agree with this but actually think we should have the bare
minimum comments in the file. Why? Because our documentation links are
static. Each setting should have the URL to the full
On Jun 1, 2008, at 21:08, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
I really need case-insensitive string comparison in my database.
Okay ... according to whose locale?
I'm using C. Of course you're correct that it depends on the locale, I
always forget that. But does
David E. Wheeler [EMAIL PROTECTED] writes:
On Jun 1, 2008, at 21:08, Tom Lane wrote:
Okay ... according to whose locale?
I'm using C. Of course you're correct that it depends on the locale, I
always forget that. But does not the Unicode standard offer up some
sort locale-independent
Joshua D. Drake [EMAIL PROTECTED] writes:
Greg Sabino Mullane wrote:
Ugh, why so much context switching? Put the docs next to the setting. URLs
are nice but not necessary. If you are arguing for minimum comments in
conf files, please make a patch for pg_hba.conf ;)
Hah! Well I don't know
David,
we wrote contrib module (mchar) for one customer, which ports its
application from mssql to postgres. It does case-insensitive comparison
for new data type 'mchar' and linked with ICU for system independent locale.
Oleg
On Sun, 1 Jun 2008, David E. Wheeler wrote:
Howdy,
I'm sure
On Jun 1, 2008, at 22:18, Tom Lane wrote:
I'm using C. Of course you're correct that it depends on the
locale, I
always forget that. But does not the Unicode standard offer up some
sort locale-independent case-insensitivity, so that it gets it right
some large percentage of the time?
Not
On Jun 1, 2008, at 22:21, Oleg Bartunov wrote:
David,
we wrote contrib module (mchar) for one customer, which ports its
application from mssql to postgres. It does case-insensitive
comparison for new data type 'mchar' and linked with ICU for system
independent locale.
That sounds
On Sun, 1 Jun 2008, David E. Wheeler wrote:
On Jun 1, 2008, at 22:21, Oleg Bartunov wrote:
David,
we wrote contrib module (mchar) for one customer, which ports its
application from mssql to postgres. It does case-insensitive comparison for
new data type 'mchar' and linked with ICU for
On Thu, 2008-05-29 at 12:05 -0700, Robert Hodges wrote:
Hi everyone,
First of all, I’m absolutely delighted that the PG community is
thinking seriously about replication.
Second, having a solid, easy-to-use database availability solution
that works more or less out of the box would be
39 matches
Mail list logo
