On Thu, 4 Oct 2001, Lamar Owen wrote:
> On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote:
> > On Tue, 2 Oct 2001, Lamar Owen wrote:
> > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote:
> > > > Time to get your act together fellas.
>
> > > This is open source John, not r
On Thu, 4 Oct 2001, Stephan Szabo wrote:
> of the message this was in response to which appears to be what Lamar was
> responding to. Besides, there's a far cry from a message of constructive
> criticism and the message this was in response to. The point that the
> documentation and reality ne
Hi,
In trying to solve a bug in 'ALTER TABLE tbl RENAME col1 TO col2',I
noticed (what must be) a typo in src/interfaces/ecpg/preproc/preproc.y
patch attached, tho it might be easier if you just look for this
line in the file:
opt_column: COLUMN { $$ = make_str
Patch rejected, please resubmit:
CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE,
PSTAT and PS_STRINGS can not be used since AIX5L does not have
appropreate header files).
--
Tatsuo Ishii
>
> > > Only problem on AIX is, that the argv[0] stuff does not work anymore
> > > (I thi
> > > Only problem on AIX is, that the argv[0] stuff does not work anymore
> > > (I think since we don't exec() anymore), which is rather annoying.
> >
> > Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX?
> > Please look at src/backend/utils/misc/ps_status.c and see if one of
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is there some sort of a system behind which places are subject to leaks
> and which places are just too lazy to call pfree()?
> I know that index support procedures must not leak, hmm, I guess this
> would include the function manager...
Yeah, that'
Tom Lane writes:
> Applied, thanks. (Looks like the leaks were introduced fairly
> recently by the dynamic-search-path feature.)
Is there some sort of a system behind which places are subject to leaks
and which places are just too lazy to call pfree()?
I know that index support procedures must
Bradley McLean <[EMAIL PROTECTED]> writes:
> 1) All of the conversion functions that return NULL ( line 1463 as
> an example, page up and down from there) will cause the backend to terminate
> abnormally. I'm not sure if this is considered a correct behavior,
> or if elog(ERROR, ...) is a better
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Sure, I said *after* we fail to find an exact match. But the "freebie"
>> match is for a function name that matches a type name and is
>> binary-compatible with the source type. That's not a weak constraint.
>> ISTM that interpretation should take p
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Not sure where pg_dump and other utilities gin up the SQL9x type names,
> but we should fix things during beta to be consistant.
I believe pg_dump and psql are already okay now that I fixed
format_type. Not sure if there are dependencies in other uti
On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote:
> On Tue, 2 Oct 2001, Lamar Owen wrote:
> > On Monday 01 October 2001 07:33 pm, John Summerfield wrote:
> > > Time to get your act together fellas.
> > This is open source John, not rocket science. (pun intended)
> Hmm. Kids I was at
> > ... then trailing zeros are hacked out,
> > two digits at a time.
> I was wondering why it seemed to always want to produce an even number
> of fractional digits. Why are you doing it 2 at a time and not 1?
> I should think timestamp(1) would produce 1 fractional digit, not
> two digits of wh
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> ... then trailing zeros are hacked out,
> two digits at a time.
I was wondering why it seemed to always want to produce an even number
of fractional digits. Why are you doing it 2 at a time and not 1?
I should think timestamp(1) would produce 1 fract
> The code asserts that SQL99 requires the default precision to be zero,
> but I do not agree with that reading. What I find is in 6.1:
> 30) If is not specified, then 0 (zero) is implicit.
> If is not specified, then 6 is implicit.
> so at the very least you'd need two diff
...
> Hmm. Somewhere else it *does* specify a precision of zero for TIME and
> TIMESTAMP; wonder why that rule wouldn't apply to CURRENT_TIME etc too?
> Not that lots of precision isn't good, but I'd like to be consistant.
Ah, I'd forgotten about the 6 vs 0 behaviors (but had them in the code
jus
...
> OK, can I get another vote for that date.
What was wrong with the 10th? I'm going to be tied up for most of the
time between now and Monday.
- Thomas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> No, it's just that CURRENT_TIMESTAMP doesn't presently reduce its
> precision, as you assert it should do. However, I see nothing in SQL99
> 6.19 that asserts anything about the precision of CURRENT_TIMESTAMP
> without a precision indicator. It just says
> 2) If specified, and
>
> Can you explain more how this functionality has changed? I know that in
> the JDBC driver fractional seconds are assumed to be two decimal places.
> If this is no longer true, I need to understand the new symantics so
> that the JDBC parsing routines can be changed. Other interfaces may
> ha
Thanks Thomas...at least there will be a way to specify more than 2. we are looking
forward to this release...
L.
On Thu, 4 Oct 2001, Thomas Lockhart wrote:
> Laurette Cisneros wrote:
> >
> > Could I get some more specific information on how this is fixed. Keep in mind
>that using tochar() i
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c .
Applied, thanks. (Looks like the leaks were introduced fairly
recently by the dynamic-search-path feature.)
> Tom, I want to notice that initGISTstate is called for every inserting
> value (fo
Patch applied. Thanks.
> Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c .
> This leaks is very significant with massive update/insert tables with gist
> indexes in one transaction or with following sequence of commands:
> 1. COPY in table large number of row
> 2. CREATE GiST index on
Thomas,
Can you explain more how this functionality has changed? I know that in
the JDBC driver fractional seconds are assumed to be two decimal places.
If this is no longer true, I need to understand the new symantics so
that the JDBC parsing routines can be changed. Other interfaces may
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
>
> > > Only problem on AIX is, that the argv[0] stuff does not work anymore
> > > (I think since we don't exec() anymore),
> > On Thu, 4 Oct 2001, Bruce Momjian wrote:
> >> Can we set a date for beta? If we are at least a week away, we should
> >> say that so people know they can keep working.
>
> I do not think we should slip it yet again, and especially not tell
> people "hey, send in more features", because that
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm going through gram.y and fixing up the implementations of
> CURRENT_TIMESTAMP et al. One point folks will run into is that
> CURRENT_TIMESTAMP *should* return time to the second, not fractions
> thereof, and CURRENT_TIMESTAMP(p) should be used to g
> On Thu, 4 Oct 2001, Bruce Momjian wrote:
>> Can we set a date for beta? If we are at least a week away, we should
>> say that so people know they can keep working.
I do not think we should slip it yet again, and especially not tell
people "hey, send in more features", because that will lead to
It seems to me that when there is no explicit precision notation
attached, a time/timestamp datatype should not force a precision of
zero, but should accept whatever it's given. This is analogous to
the way we do char, varchar, and numeric: there's no length limit
if you don't specify one. For e
Laurette Cisneros wrote:
>
> Could I get some more specific information on how this is fixed. Keep in mind that
>using tochar() is not an option for us in that we ned to use COPY to/from the client.
I'm finishing up implementing SQL99-style precision features in
timestamp et al, so there will
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Make the world safe for atttypmod=0 ... this didn't use to mean anything,
>> but timestamp now wants it to mean something.
> What was the effect of this?
coerce_type_typemod thought that typmod=0 meant it shouldn't perform any
length coercion. But
hi
By default the backend process for postgresql is 32. I
increased the N and B value and got to 140. Iam not
able to increase it any more. The present N value is
1024 and B value is 2048. Can anyone help me in this.
cheers
balsu
Do
...
> Ah, I've got it. Two problems: AdjustTimestampForTypmod is one brick
> shy of a load, and the hardwired calls to timestamp_in and friends
> weren't passing all the parameters they should. (Can anyone think of
> a way for DirectFunctionCall to do any checking?)
OK, I found the second item
> src/backend/parser: parse_coerce.c
> src/backend/utils/adt: format_type.c
> Log message:
> Make the world safe for atttypmod=0 ... this didn't use to mean anything,
> but timestamp now wants it to mean something.
What was the effect of this?
...
> I hope you're in better shape by beta time.
Hi John. I would highly recommend taking a deep breath and coming back
in a couple of weeks. Things should have settled down by then and we
will have returned to your high standards of service and support. In the
meantime, folks are busy getting u
Hi Thomas,
Could I get some more specific information on how this is fixed. Keep in mind that
using tochar() is not an option for us in that we ned to use COPY to/from the client.
Thanks,
L.
On Thu, 4 Oct 2001, Thomas Lockhart wrote:
> > Problem: the external representation of time and time
Hi Lincoln,
Not sure why you would want to run multiple instances, since you can run
multiple dbs if you want to maintain separate environments but if you really
need to do this, the postmaster has some options which control ip/port
binds:
[pritchma@blade pritchma]$ /usr/local/pgsql/bin/postmast
This is very good news. Thanks to all for the response.
L.
On Thu, 4 Oct 2001, Karel Zak wrote:
> On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote:
>
> > A work around for display might be to use to_char().
>
> In 7.2 is possible use millisecond / microsecond format:
>
> # sel
On Thu, 4 Oct 2001, John Summerfield wrote:
> On Tue, 2 Oct 2001, Bruce Momjian wrote:
>
>
> > > On Sun, 30 Sep 2001, Bruce Momjian wrote:
> > >
> > >
> > > > > On Sun, 30 Sep 2001, Bruce Momjian wrote:
> > Script attached. I could poll cvs more frequently but it seems rude to
> > hit the cvs se
Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c .
This leaks is very significant with massive update/insert tables with gist
indexes in one transaction or with following sequence of commands:
1. COPY in table large number of row
2. CREATE GiST index on table
3. VACUUM ANALYZE
On third st
> Changing the CVS repository so it doesn't work the same way any
> more isn't smart. Having wrong documentation isn't smart. Taking
> two weeks and NOT fixing a simple problem isn't smart. Giving
> wrong advice isn't smart. Test your advice - where possible I
> do.
I will consider this point val
On Thu, 4 Oct 2001, John Summerfield wrote:
> On Tue, 2 Oct 2001, Lamar Owen wrote:
>
>
> > On Monday 01 October 2001 07:33 pm, John Summerfield wrote:
> > > It seems you don't have to be new here to be a bit peeved about things;-(
> > [snip]
> > > Time to get your act together fellas.
> >
> >
Patch applied. Thanks.
> Please apply attached patch to current CVS
>
> Changes:
>
> October 1, 2001
>
> 1. Implemented binary search in array
>
> Regards,
> Oleg
> _
> Oleg Bartunov, sci.researcher, hostm
On Thu, 4 Oct 2001, Bruce Momjian wrote:
> Can we set a date for beta? If we are at least a week away, we should
> say that so people know they can keep working.
If we say the 10th I won't have to change the developer's page :)
Vince.
--
===
Appears to have been already applied. Thanks.
> You are right. Please, apply attached patch or copy result/btree_gist.out
> expected/btree_gist.out
>
>
> Tom Lane wrote:
>
> > In current CVS I see a failure in the btree_gist regression test.
> > It kinda looks like the test data was changed
On Thu, 4 Oct 2001, John Summerfield wrote:
> I know I'm not well-known here, but I've made my contributions in other arenas where
>I'm stronger.
>
> PG isn't perfect - we all know that. Nor is the project administration. When there's
>a problem identified, someone has to take responsibility fo
Can we set a date for beta? If we are at least a week away, we should
say that so people know they can keep working.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Aven
On Tue, 2 Oct 2001, Lamar Owen wrote:
> On Monday 01 October 2001 07:33 pm, John Summerfield wrote:
> > It seems you don't have to be new here to be a bit peeved about things;-(
> [snip]
> > Time to get your act together fellas.
>
> This is open source John, not rocket science. (pun intended)
H
On Tue, 2 Oct 2001, Bruce Momjian wrote:
> > On Sun, 30 Sep 2001, Bruce Momjian wrote:
> >
> >
> > > > On Sun, 30 Sep 2001, Bruce Momjian wrote:
> Script attached. I could poll cvs more frequently but it seems rude to
> hit the cvs server more frequently than every 15 minutes. If people
> want
On Tue, 2 Oct 2001, Vince Vielhaber wrote:
> On Tue, 2 Oct 2001, John Summerfield wrote:
>
> > On Mon, 1 Oct 2001, Tom Lane wrote:
> >
> >
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > The one thing I can't check is the anoncvs directory. Not sure if that
> > > > is the same as the CV
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Even stranger, this only happens on the first call to CURRENT_TIMESTAMP
> after starting a backend (example below), and stays that way if I just
> do "select current_timestamp". Something must not be initialized quite
> right, but I don't know what. An
> > Only problem on AIX is, that the argv[0] stuff does not work anymore
> > (I think since we don't exec() anymore), which is rather annoying.
>
> Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX?
> Please look at src/backend/utils/misc/ps_status.c and see if one of
> the other
Jean-Michel POURE <[EMAIL PROTECTED]> writes:
> Does CREATE OR REPLACE FUNCTION preserve function OID?
Yes. That's the whole point ...
> What it the difference with CREATE OR ALTER FUNCTION?
The former exists (now), the latter doesn't exist.
regards, tom lane
On Thu, 4 Oct 2001, Jean-Michel POURE wrote:
> Hello,
>
> Does CREATE OR REPLACE FUNCTION preserve function OID?
> What it the difference with CREATE OR ALTER FUNCTION?
>
> We would like to implement pseudo-editing of functions in pgAdmin II.
> Is there any solution which preserves function OID
> > Did we come to any conclusion about whether to accept Gavin Sherry's
> > CREATE OR REPLACE FUNCTION patch?
> > http://fts.postgresql.org/db/mw/msg.html?mid=1035792
> > AFAIR, the score was that I liked it, Bruce didn't, and no one else
> > had expressed an opinion.
>
>I withdraw my objection.
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> I'm using a redhat style postgresql init and somehow postgresql seems to
> ignore the postgresql.conf file.
That seems unlikely, assuming you are running a PG version recent enough
to have a postgresql.conf file (ie 7.1 or better). What exactly are you
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Only problem on AIX is, that the argv[0] stuff does not work anymore
> (I think since we don't exec() anymore), which is rather annoying.
Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX?
Please look at src/backend/utils/m
> Andreas, have you tried CVS tip lately on AIX? What's your results?
All 77 ok, no hangs, with make check on single CPU AIX 4.3.2.
Only problem on AIX is, that the argv[0] stuff does not work anymore
(I think since we don't exec() anymore), which is rather annoying.
Andreas
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> Perhaps it'd be a better idea for the option of a freebie
conversion
> >> to be checked earlier, say immediately after we discover there is
no
> >> exact match for the function name and input type. Thomas, what do
you
> >> think?
>
> > We *real
At 11:16 PM 03-10-2001 -0400, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
>> Is it possible for Postgresql to bind to one IP address?
>
>See 'virtual_host' GUC parameter.
>
> regards, tom lane
Thanks!
I'm using a redhat style postgresql init and somehow postg
On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote:
> A work around for display might be to use to_char().
In 7.2 is possible use millisecond / microsecond format:
# select to_char(now()+'2s 324 ms'::interval, 'HH:MM:SS MS');
to_char
--
10:10:59 324
(1 row)
# se
59 matches
Mail list logo
