Simon,
> I'd vote for a new list dedicated to discussing "Robustness" issues,
> such as PITR and the fsync/sync issues.
> The list probably would remain clearly differentiated, in the same way
> [Performance] covers lots of areas not discussed in [Hackers].
Actually, Simon, you're welcome to br
Hi Kevin,
On Tue, 3 Feb 2004, Kevin Brown wrote:
> Slavisa Garic wrote:
> > Using pg module in python I am trying to run the COPY command to populate
> > the large table. I am using this to replace the INSERT which takes about
> > few hours to add 7 entries where copy takes minute and a half.
Totally agree. Robustness and rock-solidness are the only
things missing for PostgreSQL to become the killer of certain
commercial enterprise databases out there. And the only thing
that is missing in this respect is PITR. PITR should be there
INGRES had it in '84 and some people as why PostgreSQL
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> When is beta freeze supposed to happen?
AFAIK, no date has been set at all. I doubt we'll even think about it
until we see how the Windows port effort goes.
regards, tom lane
---(end of broadcast)--
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I'd vote for a new list dedicated to discussing "Robustness" issues,
> such as PITR and the fsync/sync issues. IMHO, PostgreSQL has the
> Functionality and Performance, it just needs some rock-solid analysis of
> where-things-can-go-wrong with it, so that
>Tom Lane wrote
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Is this something large enough, like the win32 stuff, that having a
side
> > list for discussions is worth setting up?
>
> In terms of the amount of code to be written, I expect it's larger
than
> the win32 porting effort. And i
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The more finely you slice your workspace, the more likely it becomes
>> that one particular part will run out of space. So the inefficient case
>> where a backend isn't able to insert something into the appropriate list
>> will become co
On Wed, Feb 04, 2004 at 11:06:29AM -0800, Joe Conway wrote:
> Alvaro Herrera wrote:
> >I think this is most surprising behavior -- shouldn't the UPDATE raise
> >an error?
>
> Surprising, but not new (probably has been there back to the Berkley
> code), and has come up before on one of the lists (
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Instead, have each backend maintain its own separate list in shared
> > memory. The only readers of a given list would be the backend it belongs
> > to and the bgwriter, and the only time bgwriter attempts to read the
> > list is at che
On Wed, 4 Feb 2004, Michael Brusser wrote:
> We have customers who prefer to use their backup facilities
> instead of what we provide in the app (we use pg_dump)
> I hear speed is at least one consideration.
>
> The questions I need to answer are these:
>
> 1) Is this absolutely safe to do file
On 4. feb 2004, at 20:51, Peter Eisentraut wrote:
Neil Conway wrote:
David Helgason <[EMAIL PROTECTED]> writes:
I needed these, so I went and implemented them myself.
I didn't see any followup to this: do we want to include this in the
main tree, contrib/, or not at all?
getbit sounds a lot like wh
Neil,
> Granted, the primary goal should be implementing the SQL99 syntax, but
> providing syntax-level compatibility with Oracle's syntax (provided it
> isn't too difficult) seems like a good idea to me.
I don't agree. There are lots of non-standard things which Oracle does (outer
joins come t
Josh Berkus <[EMAIL PROTECTED]> writes:
> I think that's as far as we want to go implementing Oracle's syntax
Why do you think that?
> If we're to implement recursive queries, we should implement the
> SQL99 standard.
Granted, the primary goal should be implementing the SQL99 syntax, but
providi
Chris, Robert
> As a side note, I thought Joe Conway also had an implementation of
> this...
Yes, we already have a connect_by function, and have had since 7.3. Look
in /contrib/tablefuc.
I think that's as far as we want to go implementing Oracle's syntax, though
*external* patches are of
Neil Conway wrote:
> David Helgason <[EMAIL PROTECTED]> writes:
> > I needed these, so I went and implemented them myself.
>
> I didn't see any followup to this: do we want to include this in the
> main tree, contrib/, or not at all?
getbit sounds a lot like what substring() does. So perhaps setb
We have customers who prefer to use their backup facilities
instead of what we provide in the app (we use pg_dump)
I hear speed is at least one consideration.
The questions I need to answer are these:
1) Is this absolutely safe to do file copy (cpio, or
smth. else, whatever the robust backup app
Bit sets are remarkably useful functionality. I suggest putting it
into the core product.
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 04, 2004 11:22 AM
> To: David Helgason
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] implemented mi
David Helgason <[EMAIL PROTECTED]> writes:
> I needed these, so I went and implemented them myself.
I didn't see any followup to this: do we want to include this in the
main tree, contrib/, or not at all?
-Neil (who has no opinion on the matter, but just wants to make sure
this doesn't fall throu
Alvaro Herrera wrote:
I think this is most surprising behavior -- shouldn't the UPDATE raise
an error?
Surprising, but not new (probably has been there back to the Berkley
code), and has come up before on one of the lists (I think it might even
have been pgsql-bugs).
regression=# select version(
> I am concerned that the bgwriter will not be able to keep up with the
> I/O generated by even a single backend restoring a database, let alone a
> busy system. To me, the write() performed by the bgwriter, because it
> is I/O, will typically be the bottleneck on any system that is I/O bound
> (e
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> In my very personal opinion (don't cut my head off) I'd vote for both
> syntaxes.
I'm not opposed to that, although it would be a good idea to check that
Oracle doesn't have some patent covering their syntax.
However, if we g
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
Does this patch have a serious chance to make it into Pg some day?
I think Oracle's syntax is not perfect but is easy to handle and many
people are used to it. In people's mind recursive queries = CONNECT BY
and
tgl wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >> Those two cases are not hard, because in those scenarios the parser
> >> knows it is expecting a type specification. The real problem is this
> >> syntax for typed literals:
> >> typename 'string'
>
> > Just disallow that parti
Christopher Browne kirjutas K, 04.02.2004 kell 15:10:
> The fact that the form of this resembles that of the Lisp/ML "let"
> forms means that WITH can be useful in structuring queries as well.
> For instance, supposing you're computing a value that gets used
> several times, putting it into a WITH
Tom Lane kirjutas K, 04.02.2004 kell 06:04:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Wasn't there some guy at RedHat doing it?
>
> Andrew Overholt did some work on SQL99 recursive queries, but went back
> to university without having gotten to the point where it actually
> worked.
Robert Treat kirjutas K, 04.02.2004 kell 16:55:
> Seems it has no chance of getting in as it is GPL'd code... so step one
> would be convincing him to relicense it.
>
> As a side note, I thought Joe Conway also had an implementation of
> this...
IIRC Joe Conway had the simple join-by-parent-id
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Is this something large enough, like the win32 stuff, that having a side
> list for discussions is worth setting up?
In terms of the amount of code to be written, I expect it's larger than
the win32 porting effort. And it should be mostly pretty se
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> Does this patch have a serious chance to make it into Pg some day?
> I think Oracle's syntax is not perfect but is easy to handle and many
> people are used to it. In people's mind recursive queries = CONNECT BY
> and many peo
On Wed, 2004-02-04 at 05:28, Hans-Jürgen Schönig wrote:
> Christopher Kings-Lynne wrote:
> >> There is a website somewhere where a guy posts his patch he is
> >> maintaining that does it. I'll try to find it...
> >
> >
> > Found it. Check it out:
> >
> > http://gppl.terminal.ru/index.eng.html
On Wed, 4 Feb 2004, Tatsuo Ishii wrote:
> > I and some other developers are also interested in.
> > Do you think we can work together?
>
> Sure. Why not. I think it would be practical to decide who is the
> leader of this project, though.
Is this something large enough, like the win32 stuff, that
Clinging to sanity, [EMAIL PROTECTED] (Andrew Rawnsley) mumbled into her beard:
> I haven't had any problems with it so far, although I haven't really
> stressed it yet. I was going to make this very plea...
>
> I agree that the syntax can probably be improved, but its familiar to
> those of us un
Hi,
I think this is most surprising behavior -- shouldn't the UPDATE raise
an error?
alvherre=# create table foo (a int[]);
CREATE TABLE
alvherre=# insert into foo values (null);
INSERT 33649 1
alvherre=# update foo set a[3] = '42';
UPDATE 1
alvherre=# select a, a is null from foo;
a | ?column?
I haven't had any problems with it so far, although I haven't really
stressed it yet. I was going to make this very plea...
I agree that the syntax can probably be improved, but its familiar to
those of us unfortunate enough to have used (or still have to use)
Oracle. I imagine that bringing it
I would like to join this effort too.
I was afraid that people at RedHat are already
halfway though and were to release their work
shortly. But it does not seem to be the case.
Regards,
Nicolai
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On B
Christopher Kings-Lynne wrote:
There is a website somewhere where a guy posts his patch he is
maintaining that does it. I'll try to find it...
Found it. Check it out:
http://gppl.terminal.ru/index.eng.html
Patch is current for 7.4, Oracle syntax.
Chris
I had a look at the patch.
It is sti
Hi, This is Suzuki from NTT DATA Intellilink.
I told Bruce Momjan that I and my colleagues are interested in
implementing PITR in BOF in NY LW2004. NTT's laboratory is very
interested in this issue and I'm planning to work with them. I hope we
could cooperate.
Tatsuo Ishii wrote:
Has this b
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Those two cases are not hard, because in those scenarios the parser
>> knows it is expecting a type specification. The real problem is this
>> syntax for typed literals:
>> typename 'string'
> Just disallow that particular case for custom typ
Those two cases are not hard, because in those scenarios the parser
knows it is expecting a type specification. The real problem is this
syntax for typed literals:
typename 'string'
which occurs in ordinary expressions. So when you see "name(" you
aren't real sure if you're seeing
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I can't see any way to handle parameterized types without extending the
>> grammar individually for each one --- otherwise it's too hard to tell
>> them apart from function calls.
> Disallow it in table definitions, but allow it in domain defi
I can't see any way to handle parameterized types without extending the
grammar individually for each one --- otherwise it's too hard to tell
them apart from function calls. That makes it a bit hard to do 'em
as plug-ins :-(. The grammar hacks are certainly ugly though, and if
someone could think
40 matches
Mail list logo
