Re: [HACKERS] OUT parameters in PL/Java
Tom Lane wrote: Looking at the code, it appears that the java call handler *has* been called once, indeed. Obviously I didn't pay too much attention to the trace. and what it returned was a tuple that didn't carry any type identification. This is probably because you didn't call BlessTupleDesc. nodeFunctionscan.c formerly did that, and I suppose it should keep doing it for backwards compatibility. I put back the call... I hope that doesn't have a negative performance impact in general. If so, I'd be happy to add the missing BlessTupleDesc at my end instead. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Help - Urgent
Hi, I am unable to restart the PostgreSQL. I am using redhat Linux 9 with postgresql 7.4.5. Unexpectedly due to ups problem my server was shutdown once. After that i am unable to restart the server. How to stop and start. Present status is running. If i tried to start i am getting as 1) bash-2.05b$ pg_ctl start pg_ctl: Another postmaster may be running. Trying to start postmaster anyway. FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 7.3, which is not compatible with this version 7.4.5. pg_ctl: cannot start postmaster Examine the log output. 2)bash-2.05b$ pg_ctl restart /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down 3) bash-2.05b$ pg_ctl stop /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down Note: Before my server shutdown i can able to do lot of times start / stop / restart. But now i am unable to stop it. Please help me. -- Warm Regards, S.ElayaRaja Mobile: (+91) 98450 59540 E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ---(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] Help - Urgent
On Fri, 15 Apr 2005, ElayaRaja S wrote: Hi, I am unable to restart the PostgreSQL. I am using redhat Linux 9 with postgresql 7.4.5. Unexpectedly due to ups problem my server was shutdown once. After that i am unable to restart the server. DETAIL: The data directory was initialized by PostgreSQL version 7.3, which is not compatible with this version 7.4.5. pg_ctl: cannot start postmaster Sounds like you have upgraded from 7.3 to 7.4, and first now when you rebooted it tried to use the new installation. The binary data files for 7.3 does not work with 7.4. To upgrade one need to dump the old and restore into the new. The solution is most likely to downgrade to the previous version, the one that created those data files (7.3.x). -- /Dennis Björklund ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Help - Urgent
ElayaRaja S wrote: Hi, I am unable to restart the PostgreSQL. I am using redhat Linux 9 with postgresql 7.4.5. Unexpectedly due to ups problem my server was shutdown once. After that i am unable to restart the server. How to stop and start. Present status is running. If i tried to start i am getting as 1) bash-2.05b$ pg_ctl start pg_ctl: Another postmaster may be running. Trying to start postmaster anyway. FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 7.3, which is not compatible with this version 7.4.5. pg_ctl: cannot start postmaster Examine the log output. You have two versions of PostgreSQL installed (possibly one from RPM one from source). You presumably have two data directories and it is picking up the wrong one. Check $PGDATA etc. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Interactive docs idea
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 14 April 2005 18:39
To: Dave Page
Cc: Greg Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Interactive docs idea
Dave Page dpage@vale-housing.co.uk writes:
We can get from 2 - 10 a day I would guess. They get mailed
to a closed
list for moderation.
Uhm, then where are they?
On the docs. Don't forget, PHP a) probably has a lot more users than we do, b)
only keep one version of the docs online, whilst we have many and c) have been
doing this a lot longer than us.
The comments in the PHP docs, while they contain a lot of
garbage also contain
a lot of helpful tips and warnings. There's hardly any in the
Postgres docs.
See above. We do get useful comments as well as rubbish.
I think the idea of moderating the comments is inherently
flawed. You can
either have the deliberate, planned documentation without the
comments, or you
can have the wild-west style comments system, but trying to
have it both ways
is impossible. It just leads to the current situation where
the comments are
moribund.
Here's a couple of example from my inbox this morning:
[pgsql-slavestothewww] Comment 2332 added to page functions-conditional.html of
version 8.0
Author: deleted
Sou do Brasil e gostei do seu site.Prabéns!
[pgsql-slavestothewww] Comment 2333 added to page install-upgrading.html of
version 7.4
Author: Shayne Hardesty [EMAIL PROTECTED]
If you use pg_dump on an older version (say 7.1.x, 7.2.x, or 7.3.x) you will
get complains from psql about carriage returns must be represented as literal
\r. The workaround for this is to use the -d argument with pg_dump to dump as
insert statements, but that makes restore ungodly slow (prohibitively slow in
my case). In one data test I did the restore took 4 days - not workable for a
production SQL environment.
The solution I found was to put together a perl script to clean the output of
pg_dump dbname file to change carriage returns to \r. I'm sharing
my script here in hopes someone finds it useful.
-- BEGIN clean-pgdump.pl --
#!/usr/bin/perl -w
use strict;
my $file = shift @ARGV || '';
die no input file specified\n unless $file;
open(FILE, $file) || die cannot read file: $!\n;
while (FILE) {
s'\r\\\n'\\r'go;
s'\r'\\r'go;
print;
}
close(FILE);
exit;
-- END clean-pgdump.pl --
Execute the script with ./clean-pgdump.pl file newfile
Then run psql -d template1 -f newfile to import
I think it's clear we need to moderate what gets on there and what doesn't (the
first comment basically says 'I'm from Bazil and I like this site').
Whilst I'm on the subject I will also point out that early versions of the the
idocs were un-moderated and we still find garbage in there from time to time.
If anyone sees any, please email webmaster or pgsql-www with the url so we can
clean it up.
Regards, Dave.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] Help - Urgent
Hi, I am unable to restart the PostgreSQL. I am using redhat Linux 9 with postgresql 7.4.5. Unexpectedly due to ups problem my server was shutdown once. After that i am unable to restart the server. How to stop and start. Present status is running. If i tried to start i am getting as 1) bash-2.05b$ pg_ctl start pg_ctl: Another postmaster may be running. Trying to start postmaster anyway. FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 7.3, which is not compatible with this version 7.4.5. pg_ctl: cannot start postmaster Examine the log output. 2)bash-2.05b$ pg_ctl restart /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down 3) bash-2.05b$ pg_ctl stop /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down Note: Before my server shutdown i can able to do lot of times start / stop / restart. But now i am unable to stop it. Please help me. -- Warm Regards, S.ElayaRaja Mobile: (+91) 98450 59540 E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql: Done * -Use indexes for MIN() and MAX()
This is *great* news. It's certainly going to help a lot in getting legacy apps running on postgresql, where you can't change the actual queries that are being run (or can but only after fighting about it for hours and hours). And it'll do wonders to those who run amateur benchmarks and then determine that pg is slow. Many thanks, Tom (who did it, IIRC). //Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Friday, April 15, 2005 1:21 AM To: pgsql-committers@postgresql.org Subject: pgsql: Done * -Use indexes for MIN() and MAX() Log Message: --- Done * -Use indexes for MIN() and MAX() Modified Files: -- pgsql/doc: TODO (r1.1488 - r1.1489) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.dif f?r1=1.1488r2=1.1489) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] New wal_sync_method for Darwin?
I think we should add a new wal_sync_method that will use Darwin's F_FULLFSYNC fcntl(). From sys/fnctl.h: #define F_FULLFSYNC 51 /* fsync + ask the drive to flush to the media */ This fcntl() will basically perform an fsync() on the file, then flush the write cache of the disk. I'll attempt to work up the patch. It should be trivial. Might need some help on the configure tests though (it should #include sys/fcntl.h and make sure F_FULLFSYNC is defined). What's an appropriate name? It seems equivalent to fsync_writethrough. I suggest fsync_full, fsync_flushdisk, or something. Is there a reason we're not indicating the supported platform in the name of the method? Would fsync_darwinfull be better? Let users know that it's only available for Darwin? Should we do the same thing with win32-specific methods? I think both fsync() and F_FULLFSYNC should both be available as options on Darwin. Currently in the code, fsync and fsync_writethrough set sync_method to SYNC_METHOD_FSYNC, so there's no way to distinguish between them. Unsure which one would be the best default. fsync() matches the semantics on other platforms. And conscientious users could specify the F_FULLFSYNC fcntl() method if they want to make sure it goes through the write cache. Comments? Thanks! - Chris smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Why not cache stable functions?
Hello, pgsql-hackers.
I think It would be useful to cache return values for stable
and immutable functions. Now thay are really called everytime.
Demonstration (Postgresql 8.0.1 SlackWare10.0):
create table t
(
i int PRIMARY KEY
) without oids;
insert into t values (1);
insert into t values (2);
insert into t values (3);
insert into t values (4);
insert into t values (5);
insert into t values (6);
insert into t values (7);
insert into t values (8);
insert into t values (9);
insert into t values (10);
create table tt
(
x int,
y int,
PRIMARY KEY (x,y)
) without oids;
insert into tt (x,y) select t1.i,t2.i from t t1,t t2;
create function more_with_count(int,int) returns boolean as $BODY$
$_SHARED{count}++;
return (@_[0]@_[1])?'t':'f';
$BODY$
language plperl stable;
create function get_count() returns int as $BODY$
my $c=$_SHARED{count};
$_SHARED{count}=0;
return $c;
$BODY$
language plperl;
select * from tt ,t where more_with_count(tt.x,t.i);
select get_count();
/*
returns:
get_count()
---
1000
*/
Don't you think that get_count=100 is enough?
Motivation (simplified):
I have a hierarchical table for groups:
create table group
(
id int PRIMARY KEY;
pid int,
descr varchar(100),
CONSTRAINT CHECK (pid IS NULL or pidid)
);
--If pid is NULL then group is a root for some tree in a forest
--A table for group price:
create table direction
(
direction varchar(20),
group_id int,
price numeric(6,4) NOT NULL,
PRIMARY KEY (direction,group_id)
);
create index ix_direction on direction ( (direction || chr(255)), direction,
group_id )
--and (part of) table with idetified phonecalls:
create table calls
(
id_callint PRIMARY KEY,
called_nom varchar(20) NOT NULL,
group_id int
);
/*
I wish to write function like this (it may contains errors,
couse after some test on stable functions I realized it would be slow and not
test)
*/
create function is_parent_or_self(int,int) returns boolean as $BODY$
declare
this int;
descendant int;
begin
this:=$1;
descendant:=$2;
while not descendant is NULL and thisdescendant loop
select into descendant id from group where pid=descendant;
end loop;
if this=descendant then
return true;
end if;
return false;
end;
$BODY$
language plpgsql stable;
-- And set price for a call with a query
select distinct on (id_call) id_call,price
from
calls c inner join
direction d on
c.called_nom||chr(255)d.direction
and c.called_nom=d.direction
inner join
group g
on d.group_id=g.id and is_parent_or_self(c.group_id,g.id)
order by id_call,d.direction desc,g.id desc;
/* there are not more than 15 active groups from 30 total
and I think that 400 hash keys without list, so that
each hashkey equality for a different argument list would
replace previous cached value, would enough for
speed up query.
*/
Syntactically it may be formed as:
set enable_stable_function_cache=on; -- And somewhat in postgresql.conf
set max_stable_function_cache=1000;
create function ...
stable cached(400);
And I think it useful to cache values for immutable functioins
accros whole connection.
--
falcon mailto:[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Kerberos patch in the queue
Hi! I'd like to vote in favor of this patch: http://candle.pha.pa.us/mhonarc/patches2/msg00025.html. I know Tom said he didn't really like it, but I'd ask you to reconsider that. My use would be mainly for my integrate-with-active-directory project. AD requires uppercase principal names, which maens POSTGRES instead of postgres. If I could change this at runtime, that would certainly make my life a *lot* easier. I'm sure it helps in several other cases as well. (I haven't looked at the actual patch, just at the end result of it) //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Interactive docs idea
On Fri, Apr 15, 2005 at 08:42:45AM +0100, Dave Page wrote:
[pgsql-slavestothewww] Comment 2333 added to page install-upgrading.html of
version 7.4
Author: Shayne Hardesty [EMAIL PROTECTED]
If you use pg_dump on an older version (say 7.1.x, 7.2.x, or 7.3.x) you will
get complains from psql about carriage returns must be represented as literal
\r. The workaround for this is to use the -d argument with pg_dump to dump
as insert statements, but that makes restore ungodly slow (prohibitively slow
in my case). In one data test I did the restore took 4 days - not workable
for a production SQL environment.
The solution I found was to put together a perl script to clean the output of
pg_dump dbname file to change carriage returns to \r. I'm
sharing my script here in hopes someone finds it useful.
-- BEGIN clean-pgdump.pl --
#!/usr/bin/perl -w
use strict;
my $file = shift @ARGV || '';
die no input file specified\n unless $file;
open(FILE, $file) || die cannot read file: $!\n;
while (FILE) {
s'\r\\\n'\\r'go;
s'\r'\\r'go;
print;
}
close(FILE);
exit;
-- END clean-pgdump.pl --
Execute the script with ./clean-pgdump.pl file newfile
Then run psql -d template1 -f newfile to import
I think this comment is a good example of a problem with the current
system; this comment applies to both 7.4 and 8.0, but it's only in the
7.4 version. It's also long enough that it might not get into the
mainline docs (though I'm completely guessing there). It would be useful
if there was a way to have a comment cross versions.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming, or what?
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Constant time insertion into highly non-unique
On Thu, Apr 14, 2005 at 06:36:44PM +0100, Simon Riggs wrote: I'd suggest a move right probability of 97% (divide by 16) for itemsz 16 bytes and 94% (divide by 32) when itemsz = 128 Though I think functional indexes are the way to go there. Why? On a somewhat different note, what about storing or caching info about what page has free space on it? ISTM that will be much more performant than any kind of search, though you still do need to be careful about bulk-inserts. My thought is this: Go to the last page that we knew to have free space on it (last_free_page) If that page is now full, continue scanning right If we hit the end of appropriate pages, do a page split Finally, when vacuum frees space in the index, it needs to set last_free_page to the left-most page with free space, so that all free space will be used. That would be the 'greediest' version of this algorithm possible. In reality, it probably makes more sense to combine this with the current behavior, so that you have a random chance of stopping your scan to the right and just doing a page split wherever you are in the scan. This would still be a win because most of the time you'd go straight to a page with free space on it. As for storing the extra info, there's 2 possibilities that come to mind. You can either store it in the index itself, or you can cache it in shared memory. The advantage of just caching it is that you don't need to change the on-disk index format. You also wouldn't need to update something on disk every time last_free_page changes. The disadvantage is that it's probably more complex to code, and you obviously lose last_free_page info on restart and for index values that see fewer inserts as the info for those index values falls out of the cache. In either case, you only want to worry about doing this for index values that span more than a few pages (maybe the magic 3 that means you've got at least one index page that's nothing but values for this index). For more unique indexes, the extra overhead doesn't make sense. Can someone think of a way to check the performance of this idea without actually coding it? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why not cache stable functions?
falcon [EMAIL PROTECTED] writes: I think It would be useful to cache return values for stable and immutable functions. Now thay are really called everytime. In most circumstances the overhead of searching such a cache would swamp any benefit we might get from it. regards, tom lane ---(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] Why not cache stable functions?
On Fri, Apr 15, 2005 at 12:54:24PM -0400, Tom Lane wrote: falcon [EMAIL PROTECTED] writes: I think It would be useful to cache return values for stable and immutable functions. Now thay are really called everytime. In most circumstances the overhead of searching such a cache would swamp any benefit we might get from it. Maybe falcon would benefit from using pgmemcache in the first place ... -- Alvaro Herrera ([EMAIL PROTECTED]) No es bueno caminar con un hombre muerto ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Kerberos patch in the queue
Magnus Hagander [EMAIL PROTECTED] writes: I'd like to vote in favor of this patch: http://candle.pha.pa.us/mhonarc/patches2/msg00025.html. I know Tom said he didn't really like it, but I'd ask you to reconsider that. The patch is unacceptable as is because (a) it adds a libpq configuration parameter that acts differently from all the other ones (not supported in connect strings for instance) and (b) it adds no documentation for that variable, nor for the server-side variable it adds. Doing the libpq parameter in a more thorough fashion is just a matter of programming-by-example (grep for CONNECT_TIMEOUT for an example) but I for one don't know enough about Kerberos to document the thing. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Kerberos patch in the queue
I'd like to vote in favor of this patch: http://candle.pha.pa.us/mhonarc/patches2/msg00025.html. I know Tom said he didn't really like it, but I'd ask you to reconsider that. The patch is unacceptable as is because (a) it adds a libpq configuration parameter that acts differently from all the other ones (not supported in connect strings for instance) and (b) it adds no documentation for that variable, nor for the server-side variable it adds. Doing the libpq parameter in a more thorough fashion is just a matter of programming-by-example (grep for CONNECT_TIMEOUT for an example) but I for one don't know enough about Kerberos to document the thing. Daniel asked about (a) - I'm not sure if he received an answer, I couldn't find one at least. (http://candle.pha.pa.us/mhonarc/patches2/msg00024.html has the question and some more comments from him). And he offered to write up docs. Daniel, still up for doing this? If not, I can try to update the patch to address Toms concerns. Tom, assuming we fix this, are you fine with the concept? The discussion back then mentioned the another way to fail the connection. I think the gain far overweighs the pain, but it'd be nice to have that confirmed before more work is committed. //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Kerberos patch in the queue
Magnus Hagander [EMAIL PROTECTED] writes: Tom, assuming we fix this, are you fine with the concept? Mostly. Should the --with-krb-srvnam configure parameter go away? Or is it now seen as establishing an installation default? (Either way implies some documentation work.) regards, tom lane ---(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] Kerberos patch in the queue
Tom, assuming we fix this, are you fine with the concept? Mostly. Should the --with-krb-srvnam configure parameter go away? Or is it now seen as establishing an installation default? (Either way implies some documentation work.) The original way kept it in there to establish an installation default. I think that is a good idea (yes, it certainly has to be documented) to keep it as such, and just allow it to be overridden (the same way you can use --with-pgport to change the default port, but you can still override it in postgresql.conf). //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Praise (was: [ADMIN] is postgresql 8 is realy mature)
On Mon, Mar 28, 2005 at 11:22:20AM -0500, Tom Lane wrote: So far I've been very pleased with the low defect rate against 8.0. Most of the bugs we have fixed were either in new features, or were pre-existing problems that also occur in 7.4 or even further back. As usual, I've been remiss lately in keeping up with my mail, but I thought this was a good note to lean on. I fully expected a series of rather nasty surprises with the 8.0 release, given the piles of new code plus the Windows port. I think it is a real testament to the quality of Postgres hackers, and the code you produce, that there have been so few problems with 8.0. If every dot-zero release of every product were this good, people wouldn't be so gun-shy about upgrades. You folks should be extremely proud of yourselves. Good work. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Help - Urgent
Did you not see the posts by Richard and Dennis? ElayaRaja S wrote: Hi, I am unable to restart the PostgreSQL. I am using redhat Linux 9 with postgresql 7.4.5. Unexpectedly due to ups problem my server was shutdown once. After that i am unable to restart the server. How to stop and start. Present status is running. If i tried to start i am getting as 1) bash-2.05b$ pg_ctl start pg_ctl: Another postmaster may be running. Trying to start postmaster anyway. FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 7.3, which is not compatible with this version 7.4.5. pg_ctl: cannot start postmaster Examine the log output. 2)bash-2.05b$ pg_ctl restart /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down 3) bash-2.05b$ pg_ctl stop /usr/local/pgsql/bin/pg_ctl: line 274: kill: (5637) - No such process waiting for postmaster to shut down failed pg_ctl: postmaster does not shut down Note: Before my server shutdown i can able to do lot of times start / stop / restart. But now i am unable to stop it. Please help me. ---(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] argtype_inherit() is dead code
In parse_func.c there are routines argtype_inherit() and gen_cross_product() that date from Berkeley days. The comments explain their reason for existence thus: * This function is used to handle resolution of function calls when * there is no match to the given argument types, but there might be * matches based on considering complex types as members of their * superclass types (parent classes). * * It takes an array of input type ids. For each type id in the array * that's a complex type (a class), it walks up the inheritance tree, * finding all superclasses of that type. A vector of new Oid type * arrays is returned to the caller, listing possible alternative * interpretations of the input typeids as members of their superclasses * rather than the actually given argument types. The vector is * terminated by a NULL pointer. * * The order of this vector is as follows: all superclasses of the * rightmost complex class are explored first. The exploration * continues from right to left. This policy means that we favor * keeping the leftmost argument type as low in the inheritance tree * as possible. This is intentional; it is exactly what we need to * do for method dispatch. * * The vector does not include the case where no complex classes have * been promoted, since that was already tried before this routine * got called. I realized that this is effectively dead code: although it can be executed, it can never produce any useful results. The reason is that can_coerce_type() already knows that inherited rowtypes can be promoted to their parent rowtypes, and it considers that a legal implicit coercion. This means that any possible function matches based on promoting child rowtypes to ancestors were found in func_get_detail()'s first pass. If there is exactly one match then it will be taken as the correct answer and returned without calling argtype_inherit(). If there is more than one match then func_get_detail() will fail (return FUNCDETAIL_MULTIPLE), again without calling argtype_inherit(). The only way to reach argtype_inherit() is if there are *no* ancestor matches, which means that the function is a very expensive no-op that we execute just before throwing an error. I'm strongly tempted to just rip out argtype_inherit() and gen_cross_product(). Even if we suppose that we might want to resurrect the claimed functionality someday, I don't think it could be made to work this way. You'd have to put the knowledge into func_select_candidate() instead, else there'd be very weird interactions with the heuristics for resolving non-complex input argument types. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
