On Saturday 17 February 2007 07:49, RPK wrote:
> PostgreSQL, already a mature database, needs to have more options for
> recovery as compared to proprietary databases. I just worked with Oracle's
> FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
>
> Future versions of Postg
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> I remember that there was discussion about invalidating plans who's
> estimated cost turn out to be severely off when executed.
That's something we might think about after the infrastructure is in
place. But the question to answer is why the re-pla
"Chad Wagner" <[EMAIL PROTECTED]> writes:
> I am sure this topic has probably been beaten to death in the past, but has
> anyone talked about the advantages of Oracle's MVCC model versus
> PostgreSQL's MVCC model?
Yes, we've been all through that. We like ours. See the archives.
On 2/17/07, Brendan Jurd <[EMAIL PROTECTED]> wrote:
I just looked through the Oracle documentation, and it is
conspicuously silent on the topic of invalid format patterns. Much
like ours in fact.
On the case of the format: -MM-DD J, if J is the same date as -MM-DD
then Oracle appears
On 2/17/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle. Talk to an Oracle DBA
about their Rollback logs :0.
Yes, I have seen cases where undo segments are thrashed. Generally it wo
On 2/17/07, Martijn van Oosterhout wrote:
On Sat, Feb 17, 2007 at 02:41:32PM +1100, Brendan Jurd wrote:
> My gut reaction at first was to go with the former approach. It's
> programmatically more simple, and it's easier to explain in
> documentation/error messages. But then it occurred to me t
Chad Wagner wrote:
> On 2/17/07, elein <[EMAIL PROTECTED]> wrote:
>>
>> For other recent time travel ideas see:
>> http://www.varlena.com/GeneralBits/122.php
>> Time travel is not cheap, though.
>>
>
>
> I am sure this topic has probably been beaten to death in the past, but has
> anyone talked a
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I looked into this more and I think I'm afraid the proposed solution
> > actually does not work for SQL functions. For example,
>
> > CREATE OR REPLACE FUNCTION foo(INTEGER, INTEGER) RETURNS INTEGER AS $$
> > SET search_path To pg_catalog,public;
> >
Tom Lane wrote:
Relcache inval casts a fairly wide net; for example, adding or dropping an
index will invalidate all plans using the index's table whether or not
they used that particular index, and I believe that VACUUM will also
result in a relcache inval due to updating the table's pg_class r
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, Feb 08, 2007 at 01:54:13PM -0500, Tom Lane wrote:
> >> I would be satisfied if the returned command tag were something else,
> >> maybe "NO OPERATION".
>
> > "TABLE blah DID NOT EXIST" might be less confusing...
>
> You're c
Done.
* Allow SQL-language functions to reference parameters by parameter name
Currently, SQL-language functions can only refer to parameters via $1,
etc
---
Jim Nasby wrote:
> Can someone add this to the TODO?
>
[ A
Merlin Moncure wrote:
> > > This needs some revisions. The table needs to be mentioned somewhere in
> > > the
> > > text, so the reader knows when or why to refer to it. Also, the cryptic
> > > abbreviations need to be expanded or explained. And then the concept of
> > > lock "compatibility", a
Peter Eisentraut wrote:
> Am Donnerstag, 8. Februar 2007 16:32 schrieb Bruce Momjian:
> > Log Message:
> > ---
> > Add lock matrix to documentation.
>
> This needs some revisions. The table needs to be mentioned somewhere in the
> text, so the reader knows when or why to refer to it. Al
OK, I have updated "Conflicting lock modes" to show as conflicts, added
"Current/Requested" headings, add linked to the table from text. Here
is the updated version:
http://momjian.us/main/writings/pgsql/sgml/explicit-locking.html#TABLE-LOCK-COMPATIBILITY
--
On 2/17/07, elein <[EMAIL PROTECTED]> wrote:
For other recent time travel ideas see:
http://www.varlena.com/GeneralBits/122.php
Time travel is not cheap, though.
I am sure this topic has probably been beaten to death in the past, but has
anyone talked about the advantages of Oracle's MVCC mo
On Sat, Feb 17, 2007 at 11:48:55AM -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > RPK wrote:
> >> Future versions of PostgreSQL must have similar features which enable users
> >> to bring Table(s) and/or Database(s) to a desired Time Stamp.
>
> > We can do it with datab
"Matthew Campbell" <[EMAIL PROTECTED]> writes:
> revisit hash to see if we can figure it out now that we understand a little
> bit about GiST, but we can't find an equivelent function in hash for the
> KeyIsEQ().
> So two questions really. The first is if such a function exists for
> hash.
ha
On Sat, Feb 17, 2007 at 11:40:44AM -0700, Warren Turkal wrote:
> On Saturday 17 February 2007 09:26, Tom Lane wrote:
> > "Overlapping" is not an equality relation (it fails the transitive law),
> > so I'm not entirely sure what "unique" means in this context ... but I
> > can promise you you can't
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I'd also like a comment from at least one other "patch reviewer" that
>> the methods used are good.
>
> It looks reasonable as far as it goes. One thought is that pg_dump
Ok. I'll run some more tests and then get it in.
> really
Good news:
I think we've got GiST working (somewhat anyways), as we found
gistKeyIsEQ(giststate,
0, datum, currdatum) in gistutil.c does the trick of comparing two datums.
I swear most of our trouble is just finding our way around the postgres
codebase, but we're getting there little by little
On Saturday 17 February 2007 09:26, Tom Lane wrote:
> "Overlapping" is not an equality relation (it fails the transitive law),
> so I'm not entirely sure what "unique" means in this context ... but I
> can promise you you can't make it work with btree.
There is an equality relation on periods. But
On Saturday 17 February 2007 01:50, Hannu Krosing wrote:
> Is tinterval meant to be open/closed at start and end ?
I don't see the tinterval doing anything other than storing two times.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 9: In
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I'd also like a comment from at least one other "patch reviewer" that
> the methods used are good.
It looks reasonable as far as it goes. One thought is that pg_dump
really should have noticed that it was writing a broken archive.
On machines where of
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I looked into this more and I think I'm afraid the proposed solution
> actually does not work for SQL functions. For example,
> CREATE OR REPLACE FUNCTION foo(INTEGER, INTEGER) RETURNS INTEGER AS $$
> SET search_path To pg_catalog,public;
> SELECT mod($1
On 2/17/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
I have emailed Gregory, Pavan and Simon only 2 days ago, so I am not
suprised to not haven gotten feedback yet.
Oops, I haven't received the email you mentioned ? Can you resend me the
same ?
Thanks,
Pavan
--
EnterpriseDB http:/
I'm starting to think about the long-wanted plan invalidation mechanism.
Here's a sketch --- anyone see any problems?
* Create a new module, say src/backend/utils/cache/plancache.c, that we
will put in charge of all long-lived plans --- or at least those cached by
PREPARE, plpgsql, and RI triggers
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> RPK wrote:
>> Future versions of PostgreSQL must have similar features which enable users
>> to bring Table(s) and/or Database(s) to a desired Time Stamp.
> We can do it with databases, we can't do it with tables. Nor should we
> do it with tables as
Hannu Krosing <[EMAIL PROTECTED]> writes:
> How easy/hard would it be to create unique indexes on tinterval (unique
> here meaning non-overlapping) ?
"Overlapping" is not an equality relation (it fails the transitive law),
so I'm not entirely sure what "unique" means in this context ... but I
can
RPK wrote:
> PostgreSQL, already a mature database, needs to have more options for
> recovery as compared to proprietary databases. I just worked with Oracle's
> FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
>
> Future versions of PostgreSQL must have similar features wh
I find this very helpful. My head is full of patches and I rarely get
to look at things from this angle.
---
Lukas Kahwe Smith wrote:
> Lukas Kahwe Smith wrote:
>
> > I just wanted to bring up the wishlist todo items:
> >
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
Future versions of PostgreSQL must have similar features which enable users
to
On Sat, Feb 17, 2007 at 02:41:32PM +1100, Brendan Jurd wrote:
> My gut reaction at first was to go with the former approach. It's
> programmatically more simple, and it's easier to explain in
> documentation/error messages. But then it occurred to me that one of
> the use cases for to_date is slu
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
I have gotten feedback from most items on the list and I have updated
the list accordingly. Maybe a few of the items can even be moved to
"Completed" alrea
Yoshiyuki Asaba wrote:
> From: Magnus Hagander <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] pg_restore fails with a custom backup file
> Date: Fri, 16 Feb 2007 10:13:35 +0100
>
>> On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
>>
> Does not compile on my MinGW - errors in the
From: Magnus Hagander <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Fri, 16 Feb 2007 10:13:35 +0100
> On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
>
> > > > Does not compile on my MinGW - errors in the system headers (unistd.h,
> >
> > It has come to the attention of the core team of the PostgreSQL project
> > that insecure programming practice is widespread in SECURITY DEFINER
> > functions. Many of these functions are exploitable in that they allow
> > users that have the privilege to execute such a function to execute
Thanks. I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> 3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
> but may be enhanced with the GiN.
>
> Oleg
>
> On Sat, 17 Feb 2007, Tatsuo Ishii wrote:
>
> > Hi,
> >
> > Is anybody working on implementing n-gram sear
Thanks. I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> 3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
> but may be enhanced with the GiN.
>
> Oleg
>
> On Sat, 17 Feb 2007, Tatsuo Ishii wrote:
>
> > Hi,
> >
> > Is anybody working on implementing n-gram sear
Ühel kenal päeval, R, 2007-02-16 kell 17:39, kirjutas Alvaro Herrera:
> Jim C. Nasby wrote:
> > My suggestion would be to focus on a period data type first and
> > foremost, as that's something that could be readily used by a lot of
> > folks. Of particular note, it's difficult to query tables that
39 matches
Mail list logo
