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
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
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 types :P
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
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
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
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?
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
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
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
Patch is
=?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 people
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
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
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. One of
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
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 particular case for
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
=?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 go
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
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
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 through
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 missing
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
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 setbit
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
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 copy
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 checkpoint
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 (I think
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 considerably
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 it should be
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 the
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
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
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.
Simon,
I'd vote for a new list dedicated to discussing Robustness issues,
such as PITR and the fsync/sync issues.
snip
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
35 matches
Mail list logo
