Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
> -Original Message- > From: Peter Eisentraut [mailto:[EMAIL PROTECTED] > Sent: 08 October 2005 14:09 > To: Tony Marston > Cc: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1937: Parts of information_schema > only accessible to owner > > > Please copy replies to the mailing list. > > Tony Marston wrote: > > I have searched through the SQL 2003 standard and can find no such > > restriction. In the volume titled "Information and > Definition Schemas > > (SQL/Schemata)" in section 5.20 (INORMATON_SCHEMA.COLUMNS view) it > > states the following under the heading "Function": > > > > "Identify the columns of tables defined in this catalog that are > > accessible to a given user or role." > > The information schema currently follows SQL 1999. > Interestingly, the > requirement to "blank out" the column defaults of non-owned > tables was > apparently dropped in SQL 2003. Clearly, we need to review the > information schema for SQL 2003 conformance. In the mean time I have amended my version of the INFORMATION_SCHEMA.COLUMNS view to conform to the 2003 standard, so this is now a non-problem for me. I just thought that I should bring this discrepancy between the 1999 and 2003 standards to your attention. Tony Marston http://www.tonymarston.net ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 08 October 2005 22:30 > To: Jim C. Nasby > Cc: Tony Marston; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() > function > > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > And you might want to make it a project at http://pgfoundry.org so > > others can make use of it. You might also want to define it as > > accepting an array; I think that would allow you to accept > any number > > of parameters. > > I think Tony is trying to avoid putting in any actual work > ;-). To me, the sanest change would be to modify his app to > use the SQL-standard syntax. Which surely is supported by > those other databases too, no? And if not, why are *we* the > ones getting the bug report? > > regards, tom lane You are getting this as a bug report for the simple reason that your website does not seem to have a method of accepting enhancement requests. That is why I specifically put ENHANCEMENT REQUEST in the description. Tony Marston http://www.tonymarston.net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1949: Inserting Unicode hindi numbers
The following bug has been logged online: Bug reference: 1949 Logged by: Maher Abdel Karim Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows XP Description:Inserting Unicode hindi numbers Details: I have a database with UNICODE encoding. Trying to insert integers with Unicode hindi number, it fails, and the values can not be inserted to the database. and needs to re-write the numbers manually to arabic numbers. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1949: Inserting Unicode hindi numbers
> The following bug has been logged online: > > Bug reference: 1949 > Logged by: Maher Abdel Karim > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: Windows XP > Description:Inserting Unicode hindi numbers > Details: > > I have a database with UNICODE encoding. > Trying to insert integers with Unicode hindi number, it > fails, and the values can not be inserted to the database. > and needs to re-write the numbers manually to arabic numbers. The UNICODE server encoding is not supported under Windows in 8.0. This has been fixed in 8.1.For 8.0, you need to pick a different encoding. //Magnus ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
Tom Lane wrote: > Probably there are similar changes in other views. > > Not sure if there's time to do this for 8.1 ... I don't really have > time to grovel through it, do you? I don't think it's reasonable to do this for 8.1. There are probably several conceptual changes across the board that need to be attacked as a whole. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
Tony Marston wrote: > I disagree. The function description in the SQL 1999 standard says > "Identify the columns of tables defined in this catalog that are > accessible to a given user." It is clear that the actual code sample > given does not conform to this description, First of all, the current implementation certainly "identifies" all the desired columns, because you can clearly get the "identity" of all columns from that view. Moreover, the functional description does not say anything about the details of the view, leaving that to the formal definition below. If we followed your reading of the standard, the view would simply give the names of the columns along with table and schema name and that's all. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
On Sun, Oct 09, 2005 at 11:05:41AM +0100, Tony Marston wrote: > > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > And you might want to make it a project at http://pgfoundry.org > > > so others can make use of it. You might also want to define it > > > as accepting an array; I think that would allow you to accept > > > any number of parameters. > > > > I think Tony is trying to avoid putting in any actual work ;-). > > To me, the sanest change would be to modify his app to use the > > SQL-standard syntax. Which surely is supported by those other > > databases too, no? And if not, why are *we* the ones getting the > > bug report? > > > > regards, tom lane > > You are getting this as a bug report for the simple reason that your > website does not seem to have a method of accepting enhancement > requests. That is why I specifically put ENHANCEMENT REQUEST in the > description. I've never seen somebody try so hard to get himself labeled as a help-rejecting complainer before. Are you *certain* that this is what you want to do, Tony? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
> -Original Message- > From: David Fetter [mailto:[EMAIL PROTECTED] > Sent: 09 October 2005 18:20 > To: Tony Marston > Cc: 'Tom Lane'; 'Jim C. Nasby'; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function > > > On Sun, Oct 09, 2005 at 11:05:41AM +0100, Tony Marston wrote: > > > > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > > And you might want to make it a project at > http://pgfoundry.org so > > > > others can make use of it. You might also want to define it as > > > > accepting an array; I think that would allow you to accept any > > > > number of parameters. > > > > > > I think Tony is trying to avoid putting in any actual > work ;-). To > > > me, the sanest change would be to modify his app to use the > > > SQL-standard syntax. Which surely is supported by those other > > > databases too, no? And if not, why are *we* the ones > getting the bug > > > report? > > > > > > regards, tom lane > > > > You are getting this as a bug report for the simple reason > that your > > website does not seem to have a method of accepting enhancement > > requests. That is why I specifically put ENHANCEMENT REQUEST in the > > description. > > I've never seen somebody try so hard to get himself labeled > as a help-rejecting complainer before. Are you *certain* > that this is what you want to do, Tony? I am just responding in kind. If you can't take it then don't dish it out in the first place. Tony Marston http://www.tonymarston.net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
> -Original Message- > From: Peter Eisentraut [mailto:[EMAIL PROTECTED] > Sent: 09 October 2005 17:42 > To: Tony Marston > Cc: pgsql-bugs@postgresql.org; 'Stephan Szabo' > Subject: Re: [BUGS] BUG #1937: Parts of information_schema > only accessible to owner > > > Tony Marston wrote: > > I disagree. The function description in the SQL 1999 standard says > > "Identify the columns of tables defined in this catalog that are > > accessible to a given user." It is clear that the actual > code sample > > given does not conform to this description, > > First of all, the current implementation certainly > "identifies" all the > desired columns, because you can clearly get the "identity" of all > columns from that view. > > Moreover, the functional description does not say anything about the > details of the view, leaving that to the formal definition below. If > we followed your reading of the standard, the view would simply give > the names of the columns along with table and schema name and that's > all. I'm sure that if you actually implemented that interpretation you would get more complaits than you could handle. Tony Marston http://www.tonymarston.net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1950: Subroutine info cached in pl/perl
The following bug has been logged online:
Bug reference: 1950
Logged by: Greg Sabino Mullane
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 and cvs
Operating system: Linux
Description:Subroutine info cached in pl/perl
Details:
Inner subroutines seem to be caching initial values (e.g. the all important
%_TD hash)
\o /dev/null
CREATE TEMP TABLE event_problem (a int);
CREATE OR REPLACE FUNCTION event_problem() RETURNS TRIGGER LANGUAGE plperlu
AS
$$
my $event = $_TD->{event};
elog(INFO, "Top event: $event");
my $newname = $_TD->{new}{a};
elog(INFO, "Top newname : $newname");
&subber($event);
sub subber {
my $arg = shift;
elog(INFO, join " | " => caller(0));
elog(INFO, join " | " => caller(1));
elog(INFO, "Sub info : $info");
elog(INFO, "Sub global : $event");
elog(INFO, "Sub direct : $_TD->{event}");
my $newname = $_TD->{new}{a};
elog(INFO, "Sub newname : $newname");
}
elog(INFO, "Bottom event : $event");
return;
$$;
CREATE TRIGGER event_problem BEFORE INSERT ON event_problem
FOR EACH ROW EXECUTE PROCEDURE event_problem();
CREATE TRIGGER event_problem2 BEFORE UPDATE ON event_problem
FOR EACH ROW EXECUTE PROCEDURE event_problem();
-- Also happens with a single BEFORE UPDATE OR INSERT
\o
INSERT INTO event_problem(a) VALUES (22);
UPDATE event_problem SET a = 33;
INSERT INTO event_problem(a) VALUES (44);
UPDATE event_problem SET a = 55;
Outputs:
INFO: Top event: INSERT
INFO: Top newname : 22
INFO: main | (eval 1) | 8 | main::subber | 1 | | | | 0 |
INFO: main | -e | 0 | main::__ANON__ | 1 | 0 | | | 0 |
INFO: Sub info :
INFO: Sub global : INSERT
INFO: Sub direct : INSERT
INFO: Sub newname : 22
INFO: Bottom event : INSERT
INSERT 0 1
INFO: Top event: UPDATE
INFO: Top newname : 33
INFO: main | (eval 1) | 8 | main::subber | 1 | | | | 0 |
INFO: main | -e | 0 | main::__ANON__ | 1 | 0 | | | 0 |
INFO: Sub info :
INFO: Sub global : INSERT
INFO: Sub direct : INSERT
INFO: Sub newname : 22
INFO: Bottom event : UPDATE
UPDATE 1
INFO: Top event: INSERT
INFO: Top newname : 44
INFO: main | (eval 1) | 8 | main::subber | 1 | | | | 0 |
INFO: main | -e | 0 | main::__ANON__ | 1 | 0 | | | 0 |
INFO: Sub info :
INFO: Sub global : INSERT
INFO: Sub direct : INSERT
INFO: Sub newname : 22
INFO: Bottom event : INSERT
INSERT 0 1
INFO: Top event: UPDATE
INFO: Top newname : 55
INFO: main | (eval 1) | 8 | main::subber | 1 | | | | 0 |
INFO: main | -e | 0 | main::__ANON__ | 1 | 0 | | | 0 |
INFO: Sub info :
INFO: Sub global : INSERT
INFO: Sub direct : INSERT
INFO: Sub newname : 22
INFO: Bottom event : UPDATE
INFO: Top event: UPDATE
INFO: Top newname : 55
INFO: main | (eval 1) | 8 | main::subber | 1 | | | | 0 |
INFO: main | -e | 0 | main::__ANON__ | 1 | 0 | | | 0 |
INFO: Sub info :
INFO: Sub global : INSERT
INFO: Sub direct : INSERT
INFO: Sub newname : 22
INFO: Bottom event : UPDATE
UPDATE 2
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
