Re: [HACKERS] cvs

[Marc G. Fournier]

On Sun, 26 Oct 2003, Dennis Bjorklund wrote:

> What is the policy for getting cvs access?

generally based on the volume/size of patches being committed, as well as
the area of the code where patches are being applied ... if the person
responsible for applying submit'd patches (Peter in the case of
translations) feels that any one person is overwhelming him with patches
*and* has a history with the project (and of good patches), then that
person is offered commit access ...

Speaking of which, Joe, I did forget all about you *sigh* Will get onto
that this week ... please nudge me if I don't get it setup :)



---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] cvs

[Dennis Bjorklund]

On Sun, 26 Oct 2003, Marc G. Fournier wrote:

> responsible for applying submit'd patches (Peter in the case of
> translations) feels that any one person is overwhelming him with patches

It's not so much that Peter can't handle the patches but that if there is
one string that have changed to create a mail with a patch, send it, and
wait for it to be applied is a lot of extra overhead. For me that means
that trying to translate often does not work very well.

-- 
/Dennis


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Call for port reports

[Noèl Köthe]

Am So, den 26.10.2003 schrieb Bruce Momjian um 02:20:

> > (unstable)[EMAIL PROTECTED]:~/pgsql$ uname -a
> > Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux
> 
> Updated.

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

Thx. Just a minor thing. The version of s/390 should be 7.4 and not 7.3.
(maybe the same with OpenBSD/x86?)

-- 
Noèl Köthe 
Debian GNU/Linux, www.debian.org


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [HACKERS] Call for port reports

[Christopher Kings-Lynne]

I should mention that I don't have access to a FreeBSD Alpha box anymore 
:(  Hence, I have no idea if it currently compiles or not.

Chris

Peter Eisentraut wrote:

Bruce Momjian writes:


It is time for people to report their port testing.  Please test against
current CVS or beta5 and report your 'uname -a'.


FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 14:41:58 ADT 2003  i386



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] round() function wrong?

[Christopher Kings-Lynne]

refering to my math professor thats wrong, at least in germany.
select round(2.5); should return 3
Well, I thought mathematics theory says that you should round to the 
nearest even number for a 0.5 value, so as to avoid biasing your data...?

I just tried that on my 7.2.4 and 7.4 beta 4 machines and I get 2 for 
round(2.5)
What does 3.5 do?

And -2.5 and -3.5?

Chri



---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Function Permissions

[Christopher Kings-Lynne]

CREATE FUNCTION ... SECURITY DEFINER;

Read the 7.3 docs.

Chris

Telecontrol Networking wrote:

Hi,
 
I really need that a FUNCTION runs allways with this creator/owner 
permissions, and not with the user permission.
 
In other words, my FUNCTION must execute several procedures as POSTGRES 
superuser, and the tables its needs access/insert/delete/update has no 
permissions to normal user. Only calling my FUNCTION the normal user can 
do that, and never updating or deleting directly over the tables.
 
Any idea ?
 
 
-
Marco Túlio Oliveira
IT-Manager
www.telecontrol.com.br 


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [HACKERS] Timestamp docs weirdness

[Christopher Kings-Lynne]

OK, do we want to put back the mention of these in the release notes? 
The non-zulu ones sound pretty strange to me and might be better left
undocumented.
What's there to go in the release notes?  We haven't changed any code, 
and zulu is the only 'named' timezone we support (from checking source 
code).

I've just reorganised the docs, so that it's actually explained what 
they are.

Chris



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] random access - bytea

[Christopher Kings-Lynne]

This would imply that every little read would have to do a scan on a table 
to find the row and then to perform the substr. An open command can 
be optimized a lot more, for example to cache entries that have been 
opened so that it's fast to read the next 1kb or whatever you want.
It's an index scan, so it's pretty fast...

Chris



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] Coding help

[Christopher Kings-Lynne]

Hi guys,

I've asked this of a few people now, but I haven't managed to get a 
straightforward solution.

I'm working on COMMENT ON LARGE OBJECT.

If you could help me with this one, it would be really cool.  Other than
this, comment on language, conversion, cast and operator class are all done.
This is my grammar snippet.  NumericOnly seems to be the one to use -
that's what CREATE SEQUENCE uses for its large number support, and I
have to support large OIDs I presume.  I could also use IntegerOnly 
perhaps, I don't know:

| COMMENT ON LARGE OBJECT NumericOnly IS comment_text
 {
 CommentStmt *n = makeNode(CommentStmt);
 n->objtype = OBJECT_LARGEOBJECT;
 n->objname = makeList1(makeAConst($5));
 n->objargs = NIL;
 n->comment = $7;
 $$ = (Node *) n;
 }
This is my comment function:

static void
CommentLargeObject(List *qualname, char *comment)
{
 /* This is what I cannot figure out - how do I change the Node 
which is the first element in the qualname to an actual Oid type??? */
 Oidloid = somehow_get_oid_from(lfirst(qualname));
 Oidclassoid;

 /* check that the large object exists */
 if (!LargeObjectExists(loid))
 ereport(ERROR,
 (errcode(ERRCODE_UNDEFINED_OBJECT),
 errmsg("large object %u does not exist", loid)));
 classoid = get_system_catalog_relid(LargeObjectRelationName);

 CreateComments(loid, classoid, 0, comment);
}
The problem is extracting the oid from the qualname list.  I just can't
figure it out. I've searched the codebase but there doesn't seem to be
anywhere else that actually does this, like this.
I've tried all sorts of things, but I can't figure it out...

Thanks for any help,

Chris



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Call for port reports

[Kurt Roeckx]

On Sat, Oct 25, 2003 at 08:42:36PM -0400, Bruce Momjian wrote:
> 
> I am confused by your report.  I have success from Solaris kernel 5.8. 
> I see 2.6 mentioned, and I know there is Solaris 7-9.  What does uname
> -a show?

SunOS oink 5.6 Generic_105182-09 i86pc i386 i86pc

Which is the same as Solaris 2.6.


Kurt


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Call for port reports

[Dave Page]

It's rumoured that Peter Eisentraut once said:
> Bruce Momjian writes:
>
>> Uh, I am not inclined to mark the port as OK if the parallel
>> regression tests fail --- what is the cause?
>
> They always have been on Cygwin.  This platform just can't handle that
> many parallel connections.

Previously though that just resulted in a few failed tests - the run
always completed. This time I'm seeing it hang at some random point in the
tests. The one difference between now and when I've run tests previously
is that I'm now running a centrino laptop.
I'll see if I can spend some more time on it later, though I have a very
large project going live on Monday so finding time might be tricky :-(
Regards, Dave.



---(end of broadcast)---
TIP 8: explain analyze is your friend

[HACKERS] regression failure with current

[Tatsuo Ishii]

I have seen following regression failure with current(I cvs up'ed 10
minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
2.2.4.
--
Tatsuo Ishii

*** ./expected/horology.out Mon Sep 29 17:53:48 2003
--- ./results/horology.out  Sun Oct 26 20:21:59 2003
***
*** 583,595 
  SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - 
interval '1 day')) as "True";
   True 
  --
!  t
  (1 row)
  
  SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' 
+ interval '2 days')) as "True";
   True 
  --
!  t
  (1 row)
  
  SELECT (timestamp with time zone 'tomorrow' > 'now') as "True";
--- 583,595 
  SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - 
interval '1 day')) as "True";
   True 
  --
!  f
  (1 row)
  
  SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' 
+ interval '2 days')) as "True";
   True 
  --
!  f
  (1 row)
  
  SELECT (timestamp with time zone 'tomorrow' > 'now') as "True";
***
*** 836,842 
  + interval '02:01' AS time with time zone) AS time) AS "03:31:00";
   03:31:00 
  --
!  03:31:00
  (1 row)
  
  SELECT CAST(cast(date 'today' + time with time zone '03:30'
--- 836,842 
  + interval '02:01' AS time with time zone) AS time) AS "03:31:00";
   03:31:00 
  --
!  02:31:00
  (1 row)
  
  SELECT CAST(cast(date 'today' + time with time zone '03:30'

==



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] regression failure with current

[Kurt Roeckx]

On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
> I have seen following regression failure with current(I cvs up'ed 10
> minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
> 2.2.4.

Maybe the change of TZ (summer to winter time) tonight caused
this.


Kurt


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] 7.4 compatibility question

[Andrew Dunstan]

Bruce Momjian wrote:

Tatsuo Ishii wrote:
 

OK, if Tatsuo and SRA are having problems, I have to address it.  I can
supply a more detailed list to Tatsuo/SRA, or I can beef up the release
notes to contain more information.  Seems some in the community would
like to have this detail so I might as well do it and have it in the
official docs.  One idea would be to add a section at the bottom of the
release notes that goes into detail on changes listed in the release
notes above --- that way, people can still skim the 300-line release
notes, and if they want detailed information about the optimizer changes
or subtle pg_dump fixes, that will be at the bottom.
How does that sound?  I can start on this for 7.4 next week.  It
basically means going through the CVS logs again and pulling out
additional details.
 

Sounds good. However this kind of information could become huge and I
am afraid it does not suite well in the official docs in the source
tree. I think putiing it in somewhere in a web site (maybe
http://developer.postgresql.org/?) might be more appropreate.
What do you think?
   

Yes, I had thought about that --- I put something about migrating to 7.3
on a web page and put the URL in the release notes, and the URL kept
becoming invalid as they changed web configurations.  I am afraid we
have to keep this in CVS so we don't lose it over time.
It could be huge.  Current release notes for 7.4 is around 500 lines.  I
think I could do this in another 500 lines.
This is starting to sound awfully like a conventional bug tracking 
system but without the support infrastructure. Why not go the whole 
distance? Then your release notes could give the numbers and headings of 
bugs fixed  (including features added) and those who want more details 
could look at the bug reports. The process could be a whole lot less 
painful than it appears to be right now, I suspect.

cheers

andrew



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Noèl Köthe wrote:
-- Start of PGP signed section.
> Am So, den 26.10.2003 schrieb Bruce Momjian um 02:20:
> 
> > > (unstable)[EMAIL PROTECTED]:~/pgsql$ uname -a
> > > Linux raptor 2.4.19 #1 SMP Fri Nov 29 23:53:27 CET 2002 s390 GNU/Linux
> > 
> > Updated.
> 
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
> 
> Thx. Just a minor thing. The version of s/390 should be 7.4 and not 7.3.
> (maybe the same with OpenBSD/x86?)

Yep, fixed, and Freebsd/alpha too.
-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Christopher Kings-Lynne wrote:
> I should mention that I don't have access to a FreeBSD Alpha box anymore 
> :(  Hence, I have no idea if it currently compiles or not.
> 

No problem --- Peter go it.


> Chris
> 
> 
> Peter Eisentraut wrote:
> 
> > Bruce Momjian writes:
> > 
> > 
> >>It is time for people to report their port testing.  Please test against
> >>current CVS or beta5 and report your 'uname -a'.
> > 
> > 
> > FreeBSD svr1.postgresql.org 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #4: Sat Sep 20 
> > 14:41:58 ADT 2003  i386
> > 
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Ports list updated:

  http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html

Should I mention Solaris as 2.6 or 5.6?

---

Kurt Roeckx wrote:
> On Sat, Oct 25, 2003 at 08:42:36PM -0400, Bruce Momjian wrote:
> > 
> > I am confused by your report.  I have success from Solaris kernel 5.8. 
> > I see 2.6 mentioned, and I know there is Solaris 7-9.  What does uname
> > -a show?
> 
> SunOS oink 5.6 Generic_105182-09 i86pc i386 i86pc
> 
> Which is the same as Solaris 2.6.
> 
> 
> Kurt
> 
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Dave Page wrote:
> It's rumoured that Peter Eisentraut once said:
> > Bruce Momjian writes:
> >
> >> Uh, I am not inclined to mark the port as OK if the parallel
> >> regression tests fail --- what is the cause?
> >
> > They always have been on Cygwin.  This platform just can't handle that
> > many parallel connections.
> 
> Previously though that just resulted in a few failed tests - the run
> always completed. This time I'm seeing it hang at some random point in the
> tests. The one difference between now and when I've run tests previously
> is that I'm now running a centrino laptop.
> I'll see if I can spend some more time on it later, though I have a very
> large project going live on Monday so finding time might be tricky :-(
> Regards, Dave.

No problem --- the port is already marked as working --- this is a known
problem with the parallel tests.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] 7.4 compatibility question

[Bruce Momjian]

Andrew Dunstan wrote:
> >Yes, I had thought about that --- I put something about migrating to 7.3
> >on a web page and put the URL in the release notes, and the URL kept
> >becoming invalid as they changed web configurations.  I am afraid we
> >have to keep this in CVS so we don't lose it over time.
> >
> >It could be huge.  Current release notes for 7.4 is around 500 lines.  I
> >think I could do this in another 500 lines.
> >
> 
> This is starting to sound awfully like a conventional bug tracking 
> system but without the support infrastructure. Why not go the whole 
> distance? Then your release notes could give the numbers and headings of 
> bugs fixed  (including features added) and those who want more details 
> could look at the bug reports. The process could be a whole lot less 
> painful than it appears to be right now, I suspect.

Bug tracking systems have the same limitation as incremental release
notes --- youi have to do a lot of piecemeal work to get complete output
at the end, rather than doing it more efficiently in one batch.

Most people working on PostgreSQL are volunteers, and one of my primary
jobs is to make it easy for them --- if it takes me a week to get the
release notes together --- so be it --- I am making it easier for
others.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] regression failure with current

[Bruce Momjian]

Kurt Roeckx wrote:
> On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
> > I have seen following regression failure with current(I cvs up'ed 10
> > minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
> > 2.2.4.
> 
> Maybe the change of TZ (summer to winter time) tonight caused
> this.

Yes, I saw identical failures --- must be timezone.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Timestamp docs weirdness

[Bruce Momjian]

Oh, OK, sounds like we are good.

---

Christopher Kings-Lynne wrote:
> > OK, do we want to put back the mention of these in the release notes? 
> > The non-zulu ones sound pretty strange to me and might be better left
> > undocumented.
> 
> What's there to go in the release notes?  We haven't changed any code, 
> and zulu is the only 'named' timezone we support (from checking source 
> code).
> 
> I've just reorganised the docs, so that it's actually explained what 
> they are.
> 
> Chris
> 
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Call for port reports

[Kurt Roeckx]

On Sun, Oct 26, 2003 at 08:27:10AM -0500, Bruce Momjian wrote:
> 
> Ports list updated:
> 
>   http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html
> 
> Should I mention Solaris as 2.6 or 5.6?

Normally you speak about Solaris 2.5, 2.6, 7, 8 and 9.
Which are also known as SunOS 5.5, 5.6, 5.7, 5.8 and 5.9.

Either number will probably.


PS: My 2.6/5.6 was on x86 hardware, not on a sparc.


Kurt


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Call for port reports

[Dave Page]

 

> -Original Message-
> From: Dave Page 
> Sent: 26 October 2003 17:34
> To: Bruce Momjian
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Call for port reports
> 
>  
> > No problem --- the port is already marked as working --- this is a 
> > known problem with the parallel tests.
> 
> No it's not, that's what I'm saying. Normally the tests 
> finish with a few failures (because Cygwin can't create 
> enough sockets). I'm seeing a full blown hang.
>

OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
does on XP Pro).

Regards, Dave.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Question about read interval type in binary format

[Carlos Guzmán Álvarez]

Hello:

I'm trying to give support for interval type to my postgresql 7.4
ado.net provider, i want to know what is sent by the server for
interval values in binary format or where to review it ?? :)
Thanks in advance



--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Kurt Roeckx wrote:
> On Sun, Oct 26, 2003 at 08:27:10AM -0500, Bruce Momjian wrote:
> > 
> > Ports list updated:
> > 
> >   http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html
> > 
> > Should I mention Solaris as 2.6 or 5.6?
> 
> Normally you speak about Solaris 2.5, 2.6, 7, 8 and 9.
> Which are also known as SunOS 5.5, 5.6, 5.7, 5.8 and 5.9.
> 
> Either number will probably.
> 
> 
> PS: My 2.6/5.6 was on x86 hardware, not on a sparc.

Oh!  Thanks.  Updated.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Call for port reports / test horology FAILED

[Tilo Schwarz]

Hi together, keep on the nice work!

On SuSE 8.0,
> uname -a
Linux dell 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown

During compile I got the following warning:
gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes 
-Wmissing-declarations -I../../../src/include -D_GNU_SOURCE   -c trigger.c -o 
trigger.o
/tmp/ccgcppC9.s: Assembler messages:
/tmp/ccgcppC9.s:2014: Warning: using `%si' instead of `%esi' due to `w' suffix
/tmp/ccgcppC9.s:2014: Warning: using `%ax' instead of `%eax' due to `w' suffix

> as -v
GNU assembler version 2.11.92.0.10 (i486-suse-linux) using BFD version 
2.11.92.0.10 20011021 (SuSE)
> gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE)

I get the this failure (...something to do with the change to winter time last 
night?):

test horology ... FAILED, diff follows.

Bye,

Tilo

> cat src/test/regress/regression.diffs
*** ./expected/horology.out Thu Sep 25 08:58:06 2003
--- ./results/horology.out  Sun Oct 26 22:54:56 2003
***
*** 583,595 
  SELECT (timestamp with time zone 'today' = (timestamp with time zone 
'tomorrow' - interval '1 day')) as "True";
   True
  --
!  t
  (1 row)

  SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 
'yesterday' + interval '2 days')) as "True";
   True
  --
!  t
  (1 row)

  SELECT (timestamp with time zone 'tomorrow' > 'now') as "True";
--- 583,595 
  SELECT (timestamp with time zone 'today' = (timestamp with time zone 
'tomorrow' - interval '1 day')) as "True";
   True
  --
!  f
  (1 row)

  SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 
'yesterday' + interval '2 days')) as "True";
   True
  --
!  f
  (1 row)

  SELECT (timestamp with time zone 'tomorrow' > 'now') as "True";
***
*** 836,842 
  + interval '02:01' AS time with time zone) AS time) AS 
"03:31:00";
   03:31:00
  --
!  03:31:00
  (1 row)

  SELECT CAST(cast(date 'today' + time with time zone '03:30'
--- 836,842 
  + interval '02:01' AS time with time zone) AS time) AS 
"03:31:00";
   03:31:00
  --
!  02:31:00
  (1 row)

  SELECT CAST(cast(date 'today' + time with time zone '03:30'

==

*** ./expected/random.out   Thu Feb 13 06:24:04 2003
--- ./results/random.outSun Oct 26 22:55:01 2003
***
*** 25,31 
GROUP BY random HAVING count(random) > 1;
   random | count
  +---
! (0 rows)

  SELECT random FROM RANDOM_TBL
WHERE random NOT BETWEEN 80 AND 120;
--- 25,32 
GROUP BY random HAVING count(random) > 1;
   random | count
  +---
! 113 | 2
! (1 row)

  SELECT random FROM RANDOM_TBL
WHERE random NOT BETWEEN 80 AND 120;

==


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] 7.4 compatibility question

[Andrew Dunstan]

Bruce Momjian wrote:

Bug tracking systems have the same limitation as incremental release
notes --- youi have to do a lot of piecemeal work to get complete output
at the end, rather than doing it more efficiently in one batch.
Most people working on PostgreSQL are volunteers, and one of my primary
jobs is to make it easy for them --- if it takes me a week to get the
release notes together --- so be it --- I am making it easier for
others.
 

You do a fine job and I know it is appreciated.  I'd hate to think what 
would happen if you got run over by a bus.

It's a bit of a matter of taste - I think bug tracking systems give 
projects better support than mailing lists, but maybe that's just me.

cheers

andrew

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] random access - bytea

[Hannu Krosing]

Dennis Bjorklund kirjutas P, 26.10.2003 kell 07:30:
> On Sat, 25 Oct 2003, Joe Conway wrote:
> 
> > That will modify the bytea column so that it is stored uncompressed in 
> > the TOAST table.
> > 
> > Now, simply use substr() to grab any random chunk:
> > SELECT substr(foo_bytea, 2, 100) from foo where foo_id = 42;
> 
> This would imply that every little read would have to do a scan on a table 
> to find the row and then to perform the substr. An open command can 
> be optimized a lot more, for example to cache entries that have been 
> opened so that it's fast to read the next 1kb or whatever you want.
> 
> Also, the above does not solve writes at all which can also be made 
> transaction safe and fast with a better api where you can update a part 
> of a field.

I brought it up once and Tom answered that TOAST tables are not
transaction aware, so you can't update just some parts of toasted
entities - you must always write the whole fields. So this will not be
just an api change.

> The above is not really a replacement of the current lo-objects.

True.

-
Hannu


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] Question about read interval type in binary format

[Alvaro Herrera]

On Sun, Oct 26, 2003 at 11:45:49PM +0100, Carlos Guzmán Álvarez wrote:

> I'm trying to give support for interval type to my postgresql 7.4
> ado.net provider, i want to know what is sent by the server for
> interval values in binary format or where to review it ?? :)

In src/backend/utils/adt/timestamp.c, interval_send looks like what you
are looking for.

-- 
Alvaro Herrera ()
"Coge la flor que hoy nace alegre, ufana. ¿Quién sabe si nacera otra mañana?"

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Regression Test Failure/UnixWare

[Larry Rosenman]

As I posted yesterday, I've got the priviledges test failing (it's the
only one).  I posted a single-step run, and I've not heard from
anyone.
I can set up an account for anyone that want's to play with it to figure
out what I've got messed up
LER
just to refresh folks memory, here is the failure:
*** ./expected/privileges.out   Thu Oct  9 20:49:31 2003
--- ./results/privileges.outSat Oct 25 12:04:45 2003
***
*** 247,253 
 (1 row)
 CREATE FUNCTION testfunc3(int) RETURNS int AS 'select 2 * $1;' LANGUAGE 
sql; -- fail
- ERROR:  permission denied for language sql
 SET SESSION AUTHORIZATION regressuser3;
 SELECT testfunc1(5); -- fail
 ERROR:  permission denied for function testfunc1
--- 247,252 

==



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


pgp0.pgp
Description: PGP signature

Re: [HACKERS] random access - bytea

[Dennis Bjorklund]

On Sun, 26 Oct 2003, Hannu Krosing wrote:

> I brought it up once and Tom answered that TOAST tables are not
> transaction aware, so you can't update just some parts of toasted
> entities - you must always write the whole fields. So this will not be
> just an api change.

Yes, the blocks (or what one selects to work with) in a toasted field have
to have transaction stuff stored, just like tuples. That is clear if
different transactions shall have different views of the "file".

-- 
/Dennis


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection

[Jan Wieck]

Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane writes:

> What Peter was advocating in that thread was that we enable -g by
> default *when building with gcc*.  I have no problem with that, since
> there is (allegedly) no performance penalty for -g with gcc.  However,
> the actual present behavior of our configure script is to default to -g
> for every compiler, and I think that that is a big mistake.  On most
> non-gcc compilers, -g disables optimizations, which is way too high a
> price to pay for production use.
You do realize that as of now, -g is the default for gcc?  Was that the
intent?
I was going to ask that myself.  It seems strange to include -g by default ---
we have --enable-debug, and that should control -g on all platforms.
Could it be that there ought to be a difference between the defaults of 
a devel CVS tree, a BETA tarball and a final "production" release?

Jan

--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Call for port reports

[Andrew Dunstan]

- Original Message - 
From: "Dave Page" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, October 26, 2003 3:22 PM
Subject: Re: [HACKERS] Call for port reports


>
>
> > -Original Message-
> > From: Dave Page
> > Sent: 26 October 2003 17:34
> > To: Bruce Momjian
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] Call for port reports
> >
> >
> > > No problem --- the port is already marked as working --- this is a
> > > known problem with the parallel tests.
> >
> > No it's not, that's what I'm saying. Normally the tests
> > finish with a few failures (because Cygwin can't create
> > enough sockets). I'm seeing a full blown hang.
> >
>
> OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
> does on XP Pro).
>

I am seeing these hangs consistently (but not always in the same place) on
XPHE running on a P4.

uname: CYGWIN_NT-5.1 DUNSLANE 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown
unknown Cygwin

cheers

andrew


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[HACKERS] Proposed structure for coexisting major versions

[Oliver Elphick]

I sent this out a few days ago to pgsql-general.  I'm resending it in
the hope of some comment, in particular whether there is any interest in
incorporating this into PostgreSQL itself, since this may make a
difference to how I approach it.

If people aren't in favour of including it, I will go ahead with it as a
Debian package project only (unless someone reveals a horrid flaw in it
that makes it unworkable!)

  =

The attached proposal is written primarily for Debian.  Its
motivation is that the current package upgrade process is pretty flaky
and also that the current packaging does not really provide for multiple
simultaneous postmasters, which are wanted by people hosting several
database clusters.

I assume this proposal may also be of interest to Red Hat packagers.

I am copying it to the PostgreSQL list in case there are any
obvious problems that will make it impracticable or harmful and in the
hope of suggestions for its improvement.  If the general idea is
acceptable to the core team, I will rework it to be incorporated into
7.5.  The major changes would be in the directory names, which currently
assume Debian's file structure.




PostgreSQL client wrapper proposal
==


Current situation
-

When a new major version of PostgreSQL is released, it is necessary to
dump and reload the database.  The old software must be used for the dump,
and the new software for the reload.

This is a major problem for Red Hat and Debian, because a dump and reload is
not required by every upgrade and by the time the need for a dump is
realised, the old software may be deleted.  Debian has certain rather
unreliable procedures to save the old software and use it to do a dump, but
these procedures often go wrong.  Red Hat's installation environment is so
rigid that it is not practicable for the Red Hat packages to attempt an
automatic upgrade.  At the moment, Debian offers a debconf choice for
whether to attempt automatic upgrading; if it fails or is not allowed, a 
manual upgrade must be done, either from a pre-existing dump or by
manual invocation of the postgresql-dump script.

There was once an upstream program called pg_upgrade which could be used
for in-place upgrading.  This does not currently work and does not seem to
be a high priority with upstream developers.

It is possible to run different versions of PostgreSQL simultaneously, and
indeed to run the same version on separate database clusters simultaneously.
To do so, each postmaster must listen on a different port, so each client
must specify the correct port.  If it were possible to have two separate
versions of the PostgreSQL packages installed simultaneously, it would be
simple to do database upgrades by dumping from the old version and
uploading to the new.  However, the current structure of the packaging does
not permit this.



Proposed changes


I propose to change the Debian packaging to create a new package for each
major version.  The criterion for creating a new package is that initdb is
required when upgrading from the previous version. Thus, the existing
postgresql packages will become postgresql-7.3 and the new packages which
are currently in experimental will become postgresql-7.4 (and similarly
for all the binary packages).  

I propose to backport this to the current woody version (7.2.1) so that
upgrading to sarge will be made much easier.  When a new set of
versioned packages is put in the archive, the previous set should depend
on the new set, so as to force its installation.  This will enable old
packages to be removed.  All versioned packages should provide postgresql,
but there should also be a dummy postgresql package which will depend on
postgresql-7.2.  When sarge becomes the new stable release, that package
can be dropped from the archive.

Each versioned package will install into /usr/*/postgresql/{version}. 
In order to allow users easily to select the right package when working,
I propose to modify the Debian package's pg_wrapper program to read the
current version set by/for any user and to fork the correct executable
with the correct library versions according to those preferences.
/usr/bin will provide executables as soft-links to pg_wrapper.

This procedure will also allow separate database clusters to be maintained
for the use of different groups of users; these clusters need not all be
of the same major version.  This will allow much greater flexibility for
those people who need to make application software changes consequent on
a PostgreSQL upgrade.


Not really for developers
-

Since this proposal deals only with major versions of the software, it is
probably not a suitable structure for PostgreSQL developers who may want
to be running minor versions in parallel for debugging.  However, it is
important that this structure should not interfere with their ability to
do th

Re: [HACKERS] Call for port reports (Win32 Client)

[Dave Page]

 

> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
> Sent: 26 October 2003 01:35
> To: Dave Page
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Call for port reports
> 
> > NMAKE : fatal error U1077: 
> 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
> > return co
> > de '0x2'
> > Stop.
> 
> I am confused why strings.h is being included because there 
> is a test around it:
>   
>   #ifdef HAVE_STRINGS_H
>   #include 
>   #endif
> 
> Any ideas?

Yesh I forgot to remove the cygwin pg_config.h before compiling. Sorry
:-)

Anyway, I now get the error below which is not surprising as Windows
doesn't have pthreads, or pwd.h as standard.

Regards, Dave.

C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

cd include
if not exist pg_config.h copy pg_config.h.win32 pg_config.h
cd ..
cd interfaces\libpq
nmake /f win32.mak

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Building the Win32 static library...

cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma03408.
getaddrinfo.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb03408.
inet_aton.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc03408.
crypt.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd03408.
path.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme03408.
dllist.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf03408.
md5.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg03408.
ip.c
cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh03408.
thread.c
..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro
redefinition
C:\PROGRA~1\MICROS~3\VC98\INCLUDE\wingdi.h(93) : see previous
definition
 of 'ERROR'
..\..\port\thread.c(17) : fatal error C1083: Cannot open include file:
'pthread.
h': No such file or directory
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
return co
de '0x2'
Stop.

C:\cygwin\usr\local\src\postgresql-7.4beta5\src>

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] BEGIN vs START TRANSACTION

[Gaetano Mendola]

Hi all,
why START TRANSACTION READ ONLY is allowed
and not BEGIN READ ONLY ?






Regards
Gaetano Mendola
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Broken links in postgreSQL.org ads

[Stephen]

I'm using IE6 and it redirects back to http://www.postgresql.org. Mozilla
1.4 works fine.

Regards, Stephen


""Marc G. Fournier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> 'K, just tried Konqueror, and I get the same behaviour ... Firebird 0.7,
> though, works fine for me ...
>
> Just looked in Konqueror's settings for Cookies, and default is to accept
> from originating server ... IE6 has similar 'defaults', but you can setup
> P3P to get around it, do you know if Konqueror supports the same thing?
>
> Does anyone know anything about P3P?  We setup P3P for IE6, but it seems
> to still fail ... based on checks that Dave made, it apparently has to do
> with a 'short form' of P3P that needs to be sent out, but I'm not sure
> where/how to send it out ...
>
> On Fri, 24 Oct 2003, Richard Huxton wrote:
>
> > On Friday 24 October 2003 16:45, Marc G. Fournier wrote:
> > > how broken?  I just tested it from here, using Mozilla Firebird, and
they
> > > work fine, no errors ... there are issues with IE6 that we are aware
of,
> > > but again, nothing that should generate error messages ...
> >
> > I always assumed it was my settings, but they've never worked for me. It
just
> > seems to redirect back to www.postgresql.org
> >
> > Firebird 0.7 (allow unrequested popups from postgresql.org)
> > Konqueror 3.1.something
> >
> > --
> >   Richard Huxton
> >   Archonet Ltd
> >
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly
>



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Dreaming About Redesigning SQL

[Lauri Pietarinen]

Marsh Ray wrote:

Lauri Pietarinen wrote:

The theory, indeed, does not say anything about  buffer pools, but by 
decoupling logic
from implementation we leave the implementor (DBMS) to do as it feels 
fit to do.
As DBMS technology advances,  we get faster systems without having to 
change our
programs.


I think you've identified why relational systems have been the 
overwhelming winner in the business environment. They allow vendors to 
provide an optimized but fairly general solution to the interesting 
problem of efficiently accessing and storing data on rotating magnetic 
storage, while at the same time presenting a programming model that's 
at just the right level for the business applications programmer.

Relational theory or no, linked tables are typically conceptualized as 
a slight formalization of the spreadsheet, or (in earlier times) 
stacks of punched cards. As business computers evolved from more 
specific machines that could perform some relational operations on 
punched cards (sort, select, etc.), I think it's still sort of stuck 
in the collective unconscious of business to want to model their data 
this way. 
I agree with you on that one.  The punch cards history is well visible 
in the fact that in IBM-mainframes, many files have
a width of 80 chars, which just happens to be the amount of characters 
you could save on a punch card.  And, yes,
tables are often thought of as a deck of index cards, something you 
might have had in the past.

I think relational theory is useful primarily to database 
implementers, students, and those few application developers who are 
after a deeply theoretical understanding of their tools. They're 
probably the ones reading this list.

I suppose MV and other non-SQL data stores have their place in a 
certain niches (embedded systems, etc.), but the business world has 
already voted with it's feet.


What I sense is a longing for a unified environment, something that SQL 
+ [your app programming environment] does not provide.at the moment.
Hence the affection to Pick and other niche environments?

Lauri

---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] Foreign Key bug -- 7.4b4

[Gaetano Mendola]

Bruce Momjian wrote:

I can confirm this bug in CVS.


Something is cached, if you quit your psql session after
droping the constraint, and you start another psql session
the problem disappear.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] random access - bytea

[Dennis Bjorklund]

On Sun, 26 Oct 2003, Christopher Kings-Lynne wrote:

> > to find the row and then to perform the substr. An open command can 
> > be optimized a lot more, for example to cache entries that have been 
> > opened so that it's fast to read the next 1kb or whatever you want.
> 
> It's an index scan, so it's pretty fast...

And if you read a lot it will be cached, but it's still a little extra
overhead and the write case it does not solve at all.

-- 
/Dennis


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[HACKERS] ORDER BY regtype

[Christopher Kings-Lynne]

Hi guys,

Is there _any_ way of sorting by a regproc as it appears, not as its 
underlying OID?

Chris



---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Call for port reports

[Dave Page]

 

> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
> Sent: 26 October 2003 13:29
> To: Dave Page
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Call for port reports
> 
> > Previously though that just resulted in a few failed tests 
> - the run 
> > always completed. This time I'm seeing it hang at some 
> random point in 
> > the tests. The one difference between now and when I've run tests 
> > previously is that I'm now running a centrino laptop.
> > I'll see if I can spend some more time on it later, though I have a 
> > very large project going live on Monday so finding time might be 
> > tricky :-( Regards, Dave.
> 
> No problem --- the port is already marked as working --- this 
> is a known problem with the parallel tests.

No it's not, that's what I'm saying. Normally the tests finish with a
few failures (because Cygwin can't create enough sockets). I'm seeing a
full blown hang.

Regards, Dave.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Call for port reports

[Bruce Momjian]

Dave Page wrote:
>  
> 
> > -Original Message-
> > From: Dave Page 
> > Sent: 26 October 2003 17:34
> > To: Bruce Momjian
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] Call for port reports
> > 
> >  
> > > No problem --- the port is already marked as working --- this is a 
> > > known problem with the parallel tests.
> > 
> > No it's not, that's what I'm saying. Normally the tests 
> > finish with a few failures (because Cygwin can't create 
> > enough sockets). I'm seeing a full blown hang.
> >
> 
> OK, cleaned up and rebuilt & it looks OK now (well, as OK as it ever
> does on XP Pro).

OK, thanks.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] 7.4 compatibility question

[Bruce Momjian]

Andrew Dunstan wrote:
> 
> 
> Bruce Momjian wrote:
> 
> >Bug tracking systems have the same limitation as incremental release
> >notes --- youi have to do a lot of piecemeal work to get complete output
> >at the end, rather than doing it more efficiently in one batch.
> >
> >Most people working on PostgreSQL are volunteers, and one of my primary
> >jobs is to make it easy for them --- if it takes me a week to get the
> >release notes together --- so be it --- I am making it easier for
> >others.
> >  
> >
> 
> You do a fine job and I know it is appreciated.  I'd hate to think what 
> would happen if you got run over by a bus.
> 
> It's a bit of a matter of taste - I think bug tracking systems give 
> projects better support than mailing lists, but maybe that's just me.

I think our goal is to get every known problem on the TODO list so
people can scan it quickly.  It is also easier to have it all
centralized and distilled.  However, it is hard to get more detail on
the bug, so we have TODO.detail.

Bug tracking systems are an extra level of abstraction for projects in
that it categorizes discussion.  However, that abstraction level also
slows things down --- hard to say if it is a win or not.

Ideally, I would like to do all the unpleasant work and making improving
PostgreSQL easy for others.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] cvs

[Joe Conway]

Marc G. Fournier wrote:
Speaking of which, Joe, I did forget all about you *sigh* Will get onto
that this week ... please nudge me if I don't get it setup :)
No problem, I've been swamped with other things myself for a few weeks. 
I'll nudge in a few days if I don't hear back.

Joe



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Call for port reports (Win32 Client)

[Bruce Momjian]

This is all fixed in CVS --- would you try that?

---

Dave Page wrote:
>  
> 
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
> > Sent: 26 October 2003 01:35
> > To: Dave Page
> > Cc: PostgreSQL-development
> > Subject: Re: [HACKERS] Call for port reports
> > 
> > > NMAKE : fatal error U1077: 
> > 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
> > > return co
> > > de '0x2'
> > > Stop.
> > 
> > I am confused why strings.h is being included because there 
> > is a test around it:
> > 
> > #ifdef HAVE_STRINGS_H
> > #include 
> > #endif
> > 
> > Any ideas?
> 
> Yesh I forgot to remove the cygwin pg_config.h before compiling. Sorry
> :-)
> 
> Anyway, I now get the error below which is not surprising as Windows
> doesn't have pthreads, or pwd.h as standard.
> 
> Regards, Dave.
> 
> C:\cygwin\usr\local\src\postgresql-7.4beta5\src>nmake /f win32.mak
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
> cd include
> if not exist pg_config.h copy pg_config.h.win32 pg_config.h
> cd ..
> cd interfaces\libpq
> nmake /f win32.mak
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
> Building the Win32 static library...
> 
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma03408.
> getaddrinfo.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb03408.
> inet_aton.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc03408.
> crypt.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd03408.
> path.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme03408.
> dllist.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf03408.
> md5.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg03408.
> ip.c
> cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh03408.
> thread.c
> ..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro
> redefinition
> C:\PROGRA~1\MICROS~3\VC98\INCLUDE\wingdi.h(93) : see previous
> definition
>  of 'ERROR'
> ..\..\port\thread.c(17) : fatal error C1083: Cannot open include file:
> 'pthread.
> h': No such file or directory
> NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' :
> return co
> de '0x2'
> Stop.
> 
> C:\cygwin\usr\local\src\postgresql-7.4beta5\src>
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection

[Kevin Brown]

Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> > 
> > > What Peter was advocating in that thread was that we enable -g by
> > > default *when building with gcc*.  I have no problem with that, since
> > > there is (allegedly) no performance penalty for -g with gcc.  However,
> > > the actual present behavior of our configure script is to default to -g
> > > for every compiler, and I think that that is a big mistake.  On most
> > > non-gcc compilers, -g disables optimizations, which is way too high a
> > > price to pay for production use.
> > 
> > You do realize that as of now, -g is the default for gcc?

It is?

[EMAIL PROTECTED]:~/tmp$ gcc -c foo.c
[EMAIL PROTECTED]:~/tmp$ ls -l foo.o
-rw-r--r--1 kevinkevin 876 Oct 26 18:52 foo.o
[EMAIL PROTECTED]:~/tmp$ gcc -g -c foo.c
[EMAIL PROTECTED]:~/tmp$ ls -l foo.o
-rw-r--r--1 kevinkevin   12984 Oct 26 18:52 foo.o
Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs


Doesn't look like it to me...

If -g is the default, it must be very recent, in which case it's
obviously not something for our configuration scripts to rely on.

> > Was that the intent?
> 
> I was going to ask that myself.  It seems strange to include -g by default ---
> we have --enable-debug, and that should control -g on all platforms.

I thought --enable-debug had other implications, e.g. enabling assert()s
and other such things you might want enabled for debugging but not for
production.  It certainly makes sense for it to have such semantics even
if it doesn't right now.

When combined with gcc, -g is, IMO, too useful to eliminate: it makes it
possible to get good stacktraces in the face of crashes, and makes it
possible to examine variables and such when looking at core files.

> Also, -g bloats the executable, encouraging people/installers to run
> strip, which removes all symbols.  Without -g and without strip, at
> least we get function names in the backtrace.

This should be up to the individual.  I'd argue that disk space is so
plentiful and so cheap these days that executable bloat is hardly worth
considering.

But even if it were, a database tends to be so critical to so many
things that you probably want to know why and how it crashes more than
you would most other things.  So even if you might be inclined to strip
most of your binaries, you might think twice about doing the same for
the PG binaries.


-- 
Kevin Brown   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Call for port reports / test horology FAILED

[Bruce Momjian]

Tilo Schwarz wrote:
> Hi together, keep on the nice work!
> 
> On SuSE 8.0,
> > uname -a
> Linux dell 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown
> 
> During compile I got the following warning:
> gcc -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes 
> -Wmissing-declarations -I../../../src/include -D_GNU_SOURCE   -c trigger.c -o 
> trigger.o
> /tmp/ccgcppC9.s: Assembler messages:
> /tmp/ccgcppC9.s:2014: Warning: using `%si' instead of `%esi' due to `w' suffix
> /tmp/ccgcppC9.s:2014: Warning: using `%ax' instead of `%eax' due to `w' suffix
> 
> > as -v
> GNU assembler version 2.11.92.0.10 (i486-suse-linux) using BFD version 
> 2.11.92.0.10 20011021 (SuSE)
> > gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
> gcc version 2.95.3 20010315 (SuSE)

Yes, I see that with the exact same version of gcc, but it seems to
still run fine.

> I get the this failure (...something to do with the change to winter time last 
> night?):
> 
> test horology ... FAILED, diff follows.
> 

Yes, this is caused by the daylight savings time change --- it will be
OK tomorrow.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection

[Bruce Momjian]

Jan Wieck wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Tom Lane writes:
> >> 
> >> > What Peter was advocating in that thread was that we enable -g by
> >> > default *when building with gcc*.  I have no problem with that, since
> >> > there is (allegedly) no performance penalty for -g with gcc.  However,
> >> > the actual present behavior of our configure script is to default to -g
> >> > for every compiler, and I think that that is a big mistake.  On most
> >> > non-gcc compilers, -g disables optimizations, which is way too high a
> >> > price to pay for production use.
> >> 
> >> You do realize that as of now, -g is the default for gcc?  Was that the
> >> intent?
> > 
> > I was going to ask that myself.  It seems strange to include -g by default ---
> > we have --enable-debug, and that should control -g on all platforms.
> 
> Could it be that there ought to be a difference between the defaults of 
> a devel CVS tree, a BETA tarball and a final "production" release?

I am afraid that adds too much confusion to the debug situation.  We
have a flag to do -g;  let people use it if they want it.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection

[Bruce Momjian]

Kevin Brown wrote:
> > > You do realize that as of now, -g is the default for gcc?
> 
> It is?
> 
> [EMAIL PROTECTED]:~/tmp$ gcc -c foo.c
> [EMAIL PROTECTED]:~/tmp$ ls -l foo.o
> -rw-r--r--1 kevinkevin 876 Oct 26 18:52 foo.o
> [EMAIL PROTECTED]:~/tmp$ gcc -g -c foo.c
> [EMAIL PROTECTED]:~/tmp$ ls -l foo.o
> -rw-r--r--1 kevinkevin   12984 Oct 26 18:52 foo.o
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs
> 
> 
> Doesn't look like it to me...

He meant for compiling PostgreSQL using gcc, -g is the default, or was
until we changed it yesterday.  We can't use -g for non-gcc compilers
because it often turns off optimization.


> > I was going to ask that myself.  It seems strange to include -g by default ---
> > we have --enable-debug, and that should control -g on all platforms.
> 
> I thought --enable-debug had other implications, e.g. enabling assert()s
> and other such things you might want enabled for debugging but not for
> production.  It certainly makes sense for it to have such semantics even
> if it doesn't right now.

We have --enable-cassert for asserts.  Right now I only see:

# supply -g if --enable-debug
if test "$enable_debug" = yes -a "$ac_cv_prog_cc_g" = yes; then
  CFLAGS="$CFLAGS -g"
fi

> When combined with gcc, -g is, IMO, too useful to eliminate: it makes it
> possible to get good stacktraces in the face of crashes, and makes it
> possible to examine variables and such when looking at core files.

If folks want it, they can enable it, and you still get function call
names in a backtrace without -g, just not the line numbers.

> > Also, -g bloats the executable, encouraging people/installers to run
> > strip, which removes all symbols.  Without -g and without strip, at
> > least we get function names in the backtrace.
> 
> This should be up to the individual.  I'd argue that disk space is so
> plentiful and so cheap these days that executable bloat is hardly worth
> considering.
> 
> But even if it were, a database tends to be so critical to so many
> things that you probably want to know why and how it crashes more than
> you would most other things.  So even if you might be inclined to strip
> most of your binaries, you might think twice about doing the same for
> the PG binaries.

Well, we don't want to use debug for non-gcc (no optimization) so do we
do -g for gcc, and then --enable-debug does nothing.  Seems people can
decide for themselves.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] BEGIN vs START TRANSACTION

[Bruce Momjian]

Gaetano Mendola wrote:
> Hi all,
> why START TRANSACTION READ ONLY is allowed
> and not BEGIN READ ONLY ?

I think because START TRANSACTION is SQL standard?   However, I thought
BEGIN WORK was SQL standard, and we don't support READ ONLY there
either --- hmmm.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] BEGIN vs START TRANSACTION

[Christopher Kings-Lynne]

I think because START TRANSACTION is SQL standard?   However, I thought
BEGIN WORK was SQL standard, and we don't support READ ONLY there
either --- hmmm.
BEGIN is no part of the SQL standard.  The only way to begin a 
transaction under the SQL standard is START TRANSACTION.

Chris



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] regression failure with current

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Kurt Roeckx wrote:
>> On Sun, Oct 26, 2003 at 08:27:52PM +0900, Tatsuo Ishii wrote:
>>> I have seen following regression failure with current(I cvs up'ed 10
>>> minutes ago). Any thought? This is Linux kernel 2.4.22 with glibc
>>> 2.2.4.
>> 
>> Maybe the change of TZ (summer to winter time) tonight caused
>> this.

> Yes, I saw identical failures --- must be timezone.

Sheesh guys, "the horology tests fail at DST boundaries" is not only
ancient project folklore, but is well documented:
http://www.postgresql.org/docs/7.3/static/regress-evaluation.html#AEN23380
saith

: Some of the queries in the horology test will fail if you run the test
: on the day of a daylight-saving time changeover, or the day before or
: after one. These queries assume that the intervals between midnight
: yesterday, midnight today and midnight tomorrow are exactly
: twenty-four hours -- which is wrong if daylight-saving time went into
: or out of effect meanwhile.

I could understand some newbie making these complaints, but y'all have
little excuse...

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ORDER BY regtype

[Tom Lane]

Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is there _any_ way of sorting by a regproc as it appears, not as its 
> underlying OID?

Can't think of one.  If we supported casting regproc to text then I'd
expect ordering by the regproc-casted-to-text to do what you want.
But we don't.

There have been some questions in the past about why we don't support
casting *every* datatype to and from text (using the datatype's input
and output functions if necessary).  I'm on record as not favoring
allowing such conversions to happen implicitly, but I can't see any
good reason not to allow them as explicit casts...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly