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 st
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
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 a
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" <[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
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 co
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 eviden
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 functions
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, indexe
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
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. Disa
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
spec
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> after some experimentation, I came up with the attached patch,
> which implements parsing the following SERIAL types:
As has been pointed out before, it would be a seriously bad idea to
implement the SQL syntax for identity columns without matching
"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
> 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
--
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 t
Well, I certainly don't think a setof 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 simple queries
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
> 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 an
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 prob
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 p
On Sun, Jun 11, 2006 at 03:23:50PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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"?
>
Tom Lane wrote:
> Martijn van Oosterhout 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 per-datab
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
> Subject: Re: [HACKERS] pl/tcl regression failed
>
> ohp@pyrenet.fr writes:
> > I have finished buildfarm setup, just waiting for my cre
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 replace
Martijn van Oosterhout 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 that matter)
Martijn van Oosterhout wrote:
> On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
> > Martijn van Oosterhout 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 (unles
On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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+sel
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 f
Martijn van Oosterhout 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 before the read()
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
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,
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 functionalit
On Sun, Jun 11, 2006 at 02:08:12PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 ag
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 directo
Martijn van Oosterhout 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 with the wa
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 se
Ü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 neve
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 lon
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-develop
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 th
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"
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 dump
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
> Subject: Re: [HACKERS] bison version
>
> ohp@pyrenet.fr wrote:
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
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 passing
46 matches
Mail list logo
