Re: [BUGS] BUG #5926: information schema dtd_identifier for element_types, columns, parameters views inconsistent
On ons, 2011-06-08 at 11:09 -0400, Tom Lane wrote: > As far as I can tell from the spec, dtd_identifier > ought to be the identifier of the element type, while > collection_type_identifier should be a made-up identifier for the > array type. That would make the sample query given in the docs > correct. But it's collection_type_identifier that you join against, say, columns, so you can resolve the element type of column types. So collection_type_identifier must match the dtd_identifier schema of columns etc., whereas element_types.dtd_identifier is not joinable against anything. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] collation problem on 9.1-beta1
Peter Eisentraut wrote:
> On ons, 2011-05-11 at 14:58 -0400, Tom Lane wrote:
> > Marc Cousin writes:
> > > I've been starting to work on a 'what's new in 9.1' like i did last
> > > year, and am faced with what I feel is a bug, while building a demo case
> > > for collation.
> >
> > > Here it is:
> >
> > > SELECT * from (values ('llegar'),('llorer'),('lugar')) as tmp
> > > order by 1 collate "es_ES.utf8";
> > > ERROR: collations are not supported by type integer at character 74
> >
> > This isn't a bug, or at least not one we're going to fix. ORDER BY
> > column-number is a legacy syntax that doesn't support many options, and
> > COLLATE is one of the ones that it doesn't support.
Column numbers in ORDER BY is ANSI syntax so I don't think calling them
"legacy" is accurate. "limited functionality"?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] collation problem on 9.1-beta1
On tor, 2011-06-09 at 13:30 -0400, Bruce Momjian wrote: > Column numbers in ORDER BY is ANSI syntax so I don't think calling > them "legacy" is accurate. "limited functionality"? It was in SQL 92, but removed in 99, so it's technically no longer part of the standard. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] collation problem on 9.1-beta1
On Thu, Jun 9, 2011 at 2:19 PM, Peter Eisentraut wrote: > On tor, 2011-06-09 at 13:30 -0400, Bruce Momjian wrote: >> Column numbers in ORDER BY is ANSI syntax so I don't think calling >> them "legacy" is accurate. "limited functionality"? > > It was in SQL 92, but removed in 99, so it's technically no longer part > of the standard. It's still extremely widely used though, I think, and very useful. I don't feel we have to support GROUP BY 1 COLLATE whatever, but it might be worth the trouble to at least emit a decent HINT. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6050: Dump and restore of view after a schema change: can't restore the view
Robert Haas wrote: > On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane wrote: > > Robert Haas writes: > >> If your point here is that you don't want to spend time hacking on > >> this because it's a fairly marginal feature and therefore not terribly > >> high on your priority list, I can understand that. ?But if you're > >> actually defending the current implementation, I'm going to have to > >> respectfully disagree. ?It's broken, and it sucks, and this is not the > >> first complaint we've had about it. > > > > The spec's definition of USING is broken and sucky, and we're > > implementing it as best we can. ?I don't feel a need to invent > > strange nonstandard behavior to work around the fact that USING > > is fragile *by definition*. ?Complain to the standards committee > > about that. > > It's not the standard's committee's fault that our dump won't restore. > They may not have made life any easier for us, but if we're going to > have the feature, then pg_dump ought to work. Otherwise, we're > telling people "you can use this feature, but don't expect to be able > to restore from backup". Not a way to win friends. > > > (Question: would you also have us try to work around the fact that > > USING stops working if you rename one of the join columns?) > > Yeah. In fact, I proposed a patch to do just that in response to bug > #5234, which you shot down. I still don't agree with that. We can > either disallow the original DDL (adding or renaming a column in a way > that causes the dumped representation to become invalid) or we can > change what we dump so that it can be reloaded. Letting the user > change the view definition and then producing an unrestorable dump > seems truly awful to me, regardless of how little help we're getting > from the SQL standards committee. Reminder, pg_upgrade is also going to be unusuable if pg_dump generates an error, even on a view. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Fwd: Difference in postgres9.0.4 and postgres9.1beta1 when displaying error lines in functions with comments
I should have posted this here before sending it to pgsql-hackers... ups. -- Forwarded message -- From: Abel Abraham Camarillo Ojeda Date: Thu, Jun 9, 2011 at 8:58 PM Subject: Difference in postgres9.0.4 and postgres9.1beta1 when displaying error lines in functions with comments To: pgsql-hack...@postgresql.org Postgres 9.0.4 and postgres9.1beta1 give different line of error numbers on functions that raise runtime errors (it seems). How to reproduce, given the next SQL file: $ cat /tmp/sql begin; CREATE FUNCTION pg_temp.commchecksql() returns boolean strict language plpgsql as $$ begin -- SQL comment perform 'aoeuaoeuaeou'::regclass; return true; end; $$; select pg_temp.commchecksql(); rollback; begin; CREATE FUNCTION pg_temp.commcheckC() returns boolean strict language plpgsql as $$ begin /* C-like comment */ perform 'aoeuaoeuaeou'::regclass; return true; end; $$; select pg_temp.commcheckC(); rollback; -- If I run it on postgres9.0.4: $ psql -U postgres template1 -f/tmp/sql SET BEGIN CREATE FUNCTION psql:/tmp/sql:12: ERROR: relation "aoeuaoeuaeou" does not exist LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass CONTEXT: PL/pgSQL function "commchecksql" line 4 at PERFORM ROLLBACK BEGIN CREATE FUNCTION psql:/tmp/sql:26: ERROR: relation "aoeuaoeuaeou" does not exist LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass CONTEXT: PL/pgSQL function "commcheckc" line 4 at PERFORM ROLLBACK On postgres9.1beta1: $ psql -U postgres template1 -f/tmp/sql SET BEGIN CREATE FUNCTION psql:/tmp/sql:12: ERROR: relation "aoeuaoeuaeou" does not exist LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass CONTEXT: PL/pgSQL function "commchecksql" line 5 at PERFORM ROLLBACK BEGIN CREATE FUNCTION psql:/tmp/sql:26: ERROR: relation "aoeuaoeuaeou" does not exist LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass CONTEXT: PL/pgSQL function "commcheckc" line 5 at PERFORM ROLLBACK The line numbers of where the error is have changed: --- /tmp/out9.0.4 Thu Jun 9 20:47:45 2011 +++ /tmp/out9.1beta1 Thu Jun 9 20:49:02 2011 @@ -5,7 +5,7 @@ LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass -CONTEXT: PL/pgSQL function "commchecksql" line 4 at PERFORM +CONTEXT: PL/pgSQL function "commchecksql" line 5 at PERFORM ROLLBACK BEGIN CREATE FUNCTION @@ -13,5 +13,5 @@ LINE 1: SELECT 'aoeuaoeuaeou'::regclass ^ QUERY: SELECT 'aoeuaoeuaeou'::regclass -CONTEXT: PL/pgSQL function "commcheckc" line 4 at PERFORM +CONTEXT: PL/pgSQL function "commcheckc" line 5 at PERFORM ROLLBACK - I care about this because I have some custom regression tests that check the failing of functions coded like this... and they suddenly failed with that difference when I checked them against postgres9.0.4. Is this an intended behaviour? Thank you. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] collation problem on 9.1-beta1
Robert Haas wrote: > On Thu, Jun 9, 2011 at 2:19 PM, Peter Eisentraut wrote: > > On tor, 2011-06-09 at 13:30 -0400, Bruce Momjian wrote: > >> Column numbers in ORDER BY is ANSI syntax so I don't think calling > >> them "legacy" is accurate. ?"limited functionality"? > > > > It was in SQL 92, but removed in 99, so it's technically no longer part > > of the standard. Wow, they removed it; I use it all the time. > It's still extremely widely used though, I think, and very useful. I > don't feel we have to support GROUP BY 1 COLLATE whatever, but it > might be worth the trouble to at least emit a decent HINT. True. Seems now these numbers are PG extensions! -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
