Hi Gokul,
If you are saying that DDL should be auto-commit, yes, this really does
limit some use cases.
Transactional DDL is quite helpful for SQL generators, which need to avoid
leaving schema half-changed if the application crashes or there¹s a problem
with the database that causes a command to
Hi Hannu,
Hi Hannu,
On 6/1/08 2:14 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
>
>> As a consequence, I don¹t see how you can get around doing some sort
>> of row-based replication like all the other databases.
>
> Is'nt WAL-base replication "some sort of row-based replication" ?
>
Yes, in t
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 wou
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 system
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 promisin
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 rea
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 I'm
"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
"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-indepen
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
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 d
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
htt
"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
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 indexes
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 w
-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
> minimu
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
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 becau
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 ma
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
exa
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 per-tab
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
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 eithe
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 un
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> probabl
"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 un
"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 i
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
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
"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
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. Idea
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 s
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 re
"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?
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
"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_o
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
"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 hav
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;
produce
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 pr
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 tar
41 matches
Mail list logo
