On Jun 11, 2006, at 10:57 , Jim C. Nasby wrote:
On Sun, Jun 11, 2006 at 10:18:11AM +0900, Michael Glaesemann wrote:
Under design I proposed, closed-closed and closed-open are just two
different representations of the same range: to the commonly used
notation, the closed-open range [p1, p2)
On Jun 11, 2006, at 14:45 , Bruno Wolff III wrote:
On Sun, Jun 11, 2006 at 10:18:11 +0900,
Michael Glaesemann [EMAIL PROTECTED] wrote:
Time (and timestamp) is a bit of a issue conceptually. The default
successor function would depend on the precision of the timestamp.
And in the ideal
Mark Cave-Ayland wrote:
I think that Java is quite unusual in that the design of JPDA is inherently
client/server based to the point where they have defined the platform to
allow you interact with the JVM via a socket. Unfortunately the same can't
be said for Perl/Python - as you suggest
Thomas Hallgren wrote:
I'd use the Komodo IDE and implement the ability to start the PL using a
GUC setting per my original suggestion (with super-user requirement).
Trivial solution, minimum effort, and very useful. KISS principle.
The DBGp protocol [1] I mentioned earlier is used by Komodo
Hi Stefan,
Here's my make.log FWIW...
TIA
On Sat, 10 Jun 2006, Stefan Kaltenbrunner wrote:
Date: Sat, 10 Jun 2006 21:10:09 +0200
From: Stefan Kaltenbrunner [EMAIL PROTECTED]
To: ohp@pyrenet.fr
Cc: PostgreSQL-development pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] bison version
ohp@pyrenet.fr writes:
Here's my make.log FWIW...
...
gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
type_list ')'
gram.y:7078.27-7081.33: warning: useless rule: b_expr: b_expr IS NOT OF '('
type_list ')'
gmake[3]: *** [parse.h] Segmentation Fault (core dumped)
On Sun, Jun 11, 2006 at 03:22:55PM +0900, Michael Glaesemann wrote:
On Jun 11, 2006, at 14:45 , Bruno Wolff III wrote:
On Sun, Jun 11, 2006 at 10:18:11 +0900,
Michael Glaesemann [EMAIL PROTECTED] wrote:
Time (and timestamp) is a bit of a issue conceptually. The default
successor
On Sat, Jun 10, 2006 at 08:20:15PM -0700, Joshua D. Drake wrote:
Well, the argument against changing pg_dump is that it would impact the
ability to use the newer version of pg_dump with older backends (which
would be lacking these functions).
ISTM what would be best is to add the functions
Yep!
I reverted to 1.875 and it works, I'll be a member of build farm soon for
UnixWare.
On Sun, 11 Jun 2006, Tom Lane wrote:
Date: Sun, 11 Jun 2006 11:21:20 -0400
From: Tom Lane [EMAIL PROTECTED]
To: ohp@pyrenet.fr
Cc: Stefan Kaltenbrunner [EMAIL PROTECTED],
PostgreSQL-development
This has come up before, but I was reminded of it again after noticing
how confused psql gets if you use control-C to get out of a long
\lo_import operation. Usually the control-C hits while waiting for
the backend to respond to a lowrite() function call. As psql is
currently coded, it just
Ühel kenal päeval, L, 2006-06-10 kell 13:06, kirjutas Greg Stark:
But perhaps it's just worth those downsides to keep DROP/ADD a noop in more
cases.
I don't think that keeping DROP/ADD a noop in more cases. is a goal
here.
It may be a kind of semi-useful metric of design goodness, but never a
On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
I think we should try very hard to get rid of the longjmp in the signal
handler altogether. I notice it doesn't work anyway in the Windows
port, so this would improve portability as well as safety. The signal
handler should just set a
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
I think we should try very hard to get rid of the longjmp in the signal
handler altogether.
I submitted a patch for this ages ago and AFAIK it's still in the
queue. Have you any issues
Hi,
I have finished buildfarm setup, just waiting for my credentials.
However, I've install tcl 8.5a and regression tests fail like this:
ISTM it's just cosmetic, just want to share...
gmake[1]: Leaving directory
`/home4/ohp/pgfarmbuild/HEAD/pgsql.24436/src/pl/plperl'
gmake[1]: Entering
On Sun, Jun 11, 2006 at 02:08:12PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
I think we should try very hard to get rid of the longjmp in the signal
handler altogether.
I submitted a patch for this
Michael,
First off, mark me down as one of the people interested in having this ...
I've been hacking a lot of the same functionality using data-push functions
and triggers, and boy howdy, it's messy.
I do think Jim is right, though, in that we may want to look for portions of
the
On Sun, Jun 11, 2006 at 11:22:41AM -0700, Josh Berkus wrote:
You're probably going to have to give up on B-Tree indexes for PERIODs, and
look towards GiST. For one thing, I would see UNIQUE in the context of a
PERIOD defined as non-overlapping. e.g.:
If GiST could define UNIQUE indexes,
Joshua D. Drake wrote:
Well, the argument against changing pg_dump is that it would impact the
ability to use the newer version of pg_dump with older backends (which
would be lacking these functions).
ISTM what would be best is to add the functions to the backend, and add
a TODO or comments
Martijn van Oosterhout kleptog@svana.org writes:
As it states in the comment, you can't remove the longjump because
it's the only way to break out of the read() call when using BSD signal
semantics (unless you're proposing non-blocking read+select()). So the
patch sets up the sigjump just
ohp@pyrenet.fr writes:
I have finished buildfarm setup, just waiting for my credentials.
However, I've install tcl 8.5a and regression tests fail like this:
ISTM it's just cosmetic, just want to share...
Not showing the content of error messages is hardly cosmetic; it's a
serious loss of
On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
As it states in the comment, you can't remove the longjump because
it's the only way to break out of the read() call when using BSD signal
semantics (unless you're proposing
Martijn van Oosterhout wrote:
On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
As it states in the comment, you can't remove the longjump because
it's the only way to break out of the read() call when using BSD signal
semantics
Martijn van Oosterhout kleptog@svana.org writes:
If you're asking me, yes. I use it a lot and would miss it if it were
gone. Is there another shortcut for abort current command and don't
store in history but don't clear it from the screen?
Why are you expecting editing niceties (or history for
Jim C. Nasby wrote:
On Fri, Jun 09, 2006 at 06:20:21PM -0700, Trent Shipley wrote:
Ideally, the transaction management system would be proportional to the
marginal change in size of the database rather than the gross size of the
database. That is VACCUM being O(N) should be replaced (or
On Sun, 11 Jun 2006, Tom Lane wrote:
Date: Sun, 11 Jun 2006 15:03:39 -0400
From: Tom Lane [EMAIL PROTECTED]
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pl/tcl regression failed
ohp@pyrenet.fr writes:
I have finished buildfarm setup, just
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
That's why people suggest partitions. Then you only vacuum the
partitions that are new and the old ones never need to be touched...
This will all work a lot better once we track XID wraparound risk on a
per-table rather than
On Sun, Jun 11, 2006 at 03:23:50PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
If you're asking me, yes. I use it a lot and would miss it if it were
gone. Is there another shortcut for abort current command and don't
store in history but don't clear it from the
The only way that I'm aware of for disabling this is at compile time ...
after running configure, you want to modify:
src/include/pg_config.h
and undef HAVE_SETPROCTITLE ...
I'm CC'ng -hackers about this though, since I think you are the first to
point to setproctitle() as being a serious
Hi,
after some experimentation, I came up with the attached patch,
which implements parsing the following SERIAL types:
SERIAL
SERIAL GENERATED { ALWAYS | BY DEFAULT }
SERIAL GENERATED [ ALWAYS | BY DEFAULT ] AS IDENTITY( sequence options )
The underlying type is still int4 or int8,
so the
The condition (column-is_serial column-force_default)
can help enforcing GENERATED ALWAYS at INSERT time
and can also help fixing the two TODO entries about SERIAL.
You will need to include the insert components of the spec which allow
for overriding GENERATED ALWAYS during an INSERT and
Rod Taylor írta:
The condition (column-is_serial column-force_default)
can help enforcing GENERATED ALWAYS at INSERT time
and can also help fixing the two TODO entries about SERIAL.
You will need to include the insert components of the spec which allow
for overriding GENERATED ALWAYS
Well, I certainly don't think a setof name, type is adequate for
pg_get_tabledef(). What about constraints? And what you are suggesting
can probably be got by very simple queries against either the catalog or
the information schema, and seems to me to have little value.
Well it isn't
CREATE TABLE foo (id serial);
I mean, I can do either but I would like to get a clear definition of
what we are looking for here. Maybe:
pg_get_tabledef is the actual SQL and pg_get_tabledesc() is the column,
datatype output?
I guess I don't see the advantage of putting pg_dump -s -t in
On Sun, 11 Jun 2006, Kris Kennaway wrote:
Why does postgresql change its process title so frequently and how can
this be disabled? Profiling suggests it's a fairly serious
performance bottleneck.
Let's see the evidence.
regards, tom lane
Joshua D. Drake [EMAIL PROTECTED] writes:
If all you want is column, datatype, why not just use info_schema, or
newsysviews? Or even the base catalogs?
Where do I look in the info_schema? How do I know exactly what I need?
What is newsysviews?
Exactly the same arguments can be made against
Joshua D. Drake wrote:
Name and datatype was just an example. I am trying to get people to
actually provide feedback (thank you). Andrew brought up that also
including the constraints would be a good idea which I agree.
You also need rules, triggers, inheritance, indexes, primary key
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
Let's see the evidence.
The calls to setproctitle() (it looks like 4 setproctitle syscalls per
DB query) are causing contention on the Giant lock 25% of the time on
a dual p4 + HTT. Disabling
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
If all you want is column, datatype, why not just use info_schema, or
newsysviews? Or even the base catalogs?
Where do I look in the info_schema? How do I know exactly what I need?
What is newsysviews?
Exactly the same arguments can
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Name and datatype was just an example. I am trying to get people to
actually provide feedback (thank you). Andrew brought up that also
including the constraints would be a good idea which I agree.
You also need rules, triggers, inheritance,
Hello,
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
Is it to return the CREATE statements for each (where applicable)?
Is it just to create backend versions of the the identical
On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
On Sun, 11 Jun 2006, Kris Kennaway wrote:
Why does postgresql change its process title so frequently and how can
this be disabled? Profiling suggests it's a fairly serious
performance bottleneck.
Let's see the evidence.
The
On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
Let's see the evidence.
The calls to setproctitle() (it looks like 4 setproctitle syscalls per
DB query) are causing contention on
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all, but surely
the first item of work for
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all, but surely
the first
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to live at all,
On Mon, Jun 12, 2006 at 03:47:13PM +1200, Mark Kirkwood wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing
Jim C. Nasby wrote:
On Mon, Jun 12, 2006 at 03:47:13PM +1200, Mark Kirkwood wrote:
Keeping 'em separate makes sense to me:
1/ API (or info schema views) provides the required data (e.g column
details for a table).
2/ client (e.g. pg_dump) decides what to do with it (e.g. construct a
CREATE
47 matches
Mail list logo
