Re: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION

2001-06-01 Thread Michael Samuel

I've been thinking about this, and I think the smartest way to implement
%TYPE would be to have it as a special-case data type.  So, the C
representation of it would be something like this:

struct PercentType {
int datatype;
void *data;
};

Note: I made the datatype field an int, but that may/may not be the
correct datatype to use there.

And basically, postgres can resolve at runtime what it should point to,
and the code should have to deal with it, either via casting, or throwing
an exception if it's unacceptable.

Of course, there'd be a small overhead within the function, but it's a
small price to pay for a robust implementation.

As for operator overloading, a decision must be made whether you search
for a more specific function first, or for a matching %TYPE.

Of course, this may be too many special cases to be coded cleanly...

-- 
Michael Samuel [EMAIL PROTECTED]

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

http://www.postgresql.org/search.mpl



[HACKERS] bug in pg_dump with GRANT/REVOKE

2001-06-01 Thread Robert Forsman


  I'm running postgres 6.5.3 and 7.0.3 and pg_dump gives me the following
output:

DROP TABLE genrenametable;
CREATE TABLE genrenametable (
genreid int4,
name character varying(128),
parentgenre int4,
enabled bool DEFAULT 'f' NOT NULL
);
REVOKE ALL on genrenametable from PUBLIC;
GRANT SELECT on genrenametable to hammor;
GRANT SELECT on genrenametable to johnbr;
COPY genrenametable FROM stdin;
411580s Alt Hits4096t
4138New Wave Hits   4096t
411790s Alt Hits4096t
...

  As you can guess, this will not successfully restore the table.

  Perhaps the REVOKE/GRANT statements can be moved to after the COPY. 

  The fancy solution would be to make sure the table owner has
permissions to do the COPY, and then revoke the permissions afterward if
necessary.

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



[HACKERS] dump+reload?

2001-06-01 Thread gabriel


hello all

How can i do dump and reload in all databases?

thanks...

---(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: Fwd: Re: [HACKERS] Shared memory for RH Linux 7.1

2001-06-01 Thread Michael J Schout

On Thu, 24 May 2001, Ryan Mahoney wrote:

 This is true.  You can adjust the value in the /proc/sys/kernel/shmmax 
 file.  If you change the value it will be reset when you reboot, so you 
 will need to write a start-up script to always change this value if you 
 want it to be permanent.

or you can let sysctl do it with this in /etc/sysctl.conf:

kernel.shmmax = 268435456

(obviously changing the value with what is appropriate for your machine).

This is for a RH 6.2 box.  DOnt know if its the same on 7.1.  We switched to
FreeBSD between redhat 6.2 and 7.0, so we dont have any RH7.1 boxes laying
around.  I suspect it hasn't changed though.

Mike


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

http://www.postgresql.org/users-lounge/docs/faq.html



AW: [HACKERS] Access statistics

2001-06-01 Thread Zeugswetter Andreas SB

 One more feature for discussion :-)
 
 In  the  next  couple of hours (at least tomorrow) I would be
 ready to commit the backend changes  for  table-/index-access
 statistics and current backend activity views.
 
 Should  I  apply  the patches or provide a separate patch for
 review first?

One concern I remember from memory was, that the table names
did not conform to the system table semantics of pg_*. (pgstat_*)
Have you, or would you change that ?

Andreas

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



AW: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION

2001-06-01 Thread Zeugswetter Andreas SB


  AND  expect  it  to  do  more  than that.  So a NOTICE at the
  actual usage, telling that  x%TYPE  for  y  got  resolved  to
  basetype  z  and will currently NOT follow later changes to x
  should do it.
 
 So if you could implement it like that, we will be VERY happy.

I also like that approach.

Andreas


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



Re: [HACKERS] ERROR: cache lookup for proc 43030134 failed

2001-06-01 Thread Tom Lane

Kovacs Zoltan [EMAIL PROTECTED] writes:
 I think not.  The current implementation of LIMIT fetches one more row
 than is really needed, IIRC.

 Tom, the real problem is that I get _different_ output for 

The point is that the problem is probably in the 23rd row of pg_class,
not the 22nd.

regards, tom lane

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

http://www.postgresql.org/search.mpl



Re: [HACKERS] Access statistics

2001-06-01 Thread Tom Lane

Jan Wieck [EMAIL PROTECTED] writes:
 So outing myself not beeing a *real programmer*, this is what
 I have so far:

Hmm ... what is the performance of all this like?  Seems like a lot
of overhead.  Can it be turned off?

 * Backends call some collector functions  at  various  places
   now  (these  will  finally  be macros), that count up table
   scans, tuples returned by scans,  buffer  fetches/hits  and
   the like.

Have you removed the existing stats-gathering support
(backend/access/heap/stats.c and so on)?   That would buy back
at least a few of the cycles involved ...

regards, tom lane

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

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] Access statistics

2001-06-01 Thread Tom Lane

Jan Wieck [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Have you removed the existing stats-gathering support
 (backend/access/heap/stats.c and so on)?   That would buy back
 at least a few of the cycles involved ...

 Not sure if we really should.  Let's  later  decide  if  it's
 really obsolete.

Considering that Bruce long ago ifdef'd out all the code that could
actually *do* anything with those stats (like print them), I'd say
it's obsolete.  In any case, it's too confusing to have two sets of
stats-gathering code in there.  I vote for getting rid of the old
stuff.

regards, tom lane

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



Re: [HACKERS] Re: Interesting Atricle

2001-06-01 Thread Ryan Mahoney

I think there is really something weird about the Zend site - I use the 
current IE on an NT machine, and every page loads, but then I have to wait 
about 10 additional seconds before IE wakes up and I can click any links 
or go to a different page.

I think it may have something to do with the DHTML menus... but I haven't 
really looked into it.

-r

At 09:18 PM 6/1/01 -0400, Bruce Momjian wrote:

   Thought some people might find this article interesting.
   http://www.zend.com/zend/art/databases.php
 
  The only interesting thing I noticed is how fast it crashes my
  Netscape-4.76 browser ;)

Yours too?  I turned off Java/Javascript to get it to load and I am on
BSD/OS.  Strange it so univerally crashes.

--
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (610) 853-3000
   +  If your life is a hard drive, |  830 Blythe Avenue
   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

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

http://www.postgresql.org/search.mpl



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01



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