[BUGS] BUG #5534: IS DOCUMENT predicate errors instead of returning false
The following bug has been logged online: Bug reference: 5534 Logged by: Mike Fowler Email address: m...@mlfowler.com PostgreSQL version: 9.0beta2 Operating system: Linux 2.6.31-14-generic #48-Ubuntu SMP Description:IS DOCUMENT predicate errors instead of returning false Details: IS DOCUMENT should return false for a non-well formed document, and indeed is coded to do such. However, the conversion to the xml type which happens before the underlying xml_is_document function is even called fails and exceptions out. I've mentioned this on -hackers with message ID 20100701172553.w5vdy1xbocos8...@www.mlfowler.com -- 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 #5534: IS DOCUMENT predicate errors instead of returning false
Quoting Mike Fowler :
The following bug has been logged online:
Bug reference: 5534
Logged by: Mike Fowler
Email address: m...@mlfowler.com
PostgreSQL version: 9.0beta2
Operating system: Linux 2.6.31-14-generic #48-Ubuntu SMP
Description:IS DOCUMENT predicate errors instead of returning false
Details:
IS DOCUMENT should return false for a non-well formed document, and indeed
is coded to do such. However, the conversion to the xml type which happens
before the underlying xml_is_document function is even called fails and
exceptions out. I've mentioned this on -hackers with message ID
20100701172553.w5vdy1xbocos8...@www.mlfowler.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The attached patch is a very small patch that changes parse_expr.c to
not convert everything to xml. This now means that when passed
malformed XML it will return false instead of throwing an exception.
In my mind this acceptable as I don't see anywhere in the standard
that mandates that:
xmlval IS NOT DOCUMENT == xmlval IS CONTENT
Regards,
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
***
*** 1950,1956 transformXmlExpr(ParseState *pstate, XmlExpr *x)
Assert(false);
break;
case IS_DOCUMENT:
! newe = coerce_to_specific_type(pstate, newe, XMLOID,
"IS DOCUMENT");
break;
}
--- 1950,1956
Assert(false);
break;
case IS_DOCUMENT:
! newe = coerce_to_specific_type(pstate, newe, TEXTOID,
"IS DOCUMENT");
break;
}
*** a/src/backend/utils/adt/xml.c
--- b/src/backend/utils/adt/xml.c
***
*** 795,801 xmlvalidate(PG_FUNCTION_ARGS)
bool
! xml_is_document(xmltype *arg)
{
#ifdef USE_LIBXML
bool result;
--- 795,801
bool
! xml_is_document(text *arg)
{
#ifdef USE_LIBXML
bool result;
***
*** 805,811 xml_is_document(xmltype *arg)
/* We want to catch ereport(INVALID_XML_DOCUMENT) and return false */
PG_TRY();
{
! doc = xml_parse((text *) arg, XMLOPTION_DOCUMENT, true,
GetDatabaseEncoding());
result = true;
}
--- 805,811
/* We want to catch ereport(INVALID_XML_DOCUMENT) and return false */
PG_TRY();
{
! doc = xml_parse(arg, XMLOPTION_DOCUMENT, true,
GetDatabaseEncoding());
result = true;
}
*** a/src/include/utils/xml.h
--- b/src/include/utils/xml.h
***
*** 70,76 extern xmltype *xmlelement(XmlExprState *xmlExpr, ExprContext *econtext);
extern xmltype *xmlparse(text *data, XmlOptionType xmloption, bool preserve_whitespace);
extern xmltype *xmlpi(char *target, text *arg, bool arg_is_null, bool *result_is_null);
extern xmltype *xmlroot(xmltype *data, text *version, int standalone);
! extern bool xml_is_document(xmltype *arg);
extern text *xmltotext_with_xmloption(xmltype *data, XmlOptionType xmloption_arg);
extern char *escape_xml(const char *str);
--- 70,76
extern xmltype *xmlparse(text *data, XmlOptionType xmloption, bool preserve_whitespace);
extern xmltype *xmlpi(char *target, text *arg, bool arg_is_null, bool *result_is_null);
extern xmltype *xmlroot(xmltype *data, text *version, int standalone);
! extern bool xml_is_document(text *arg);
extern text *xmltotext_with_xmloption(xmltype *data, XmlOptionType xmloption_arg);
extern char *escape_xml(const char *str);
*** a/src/test/regress/expected/xml.out
--- b/src/test/regress/expected/xml.out
***
*** 357,362 SELECT xml 'bar' IS DOCUMENT;
--- 357,378
t
(1 row)
+ SELECT xml 'barbar'
+ barbarbarbarfoo' IS DOCUMENT;
?column?
--
***
*** 376,387 SELECT xml 'abc' IS NOT DOCUMENT;
(1 row)
SELECT '<>' IS NOT DOCUMENT;
ERROR: invalid XML content
! LINE 1: SELECT '<>' IS NOT DOCUMENT;
!^
! DETAIL: Entity: line 1: parser error : StartTag: invalid element name
! <>
! ^
SELECT xmlagg(data) FROM xmltest;
xmlagg
--
--- 392,418
(1 row)
SELECT '<>' IS NOT DOCUMENT;
+ ?column?
+ --
+ t
+ (1 row)
+
+ SELECT xml 'barbar'
! barbarbarbar' IS DOCUMENT;
+ SELECT xml 'barbarbarfoo' IS DOCUMENT;
SELECT xml '' IS NOT DOCUMENT;
SELECT xml 'abc' IS NOT DOCUMENT;
SELECT '<>' IS NOT DOCUMENT;
+ SELECT xml 'barbar
--
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] LINE COMMAND
On 16/08/10 15:03, Felipe Lopes wrote: I would like to run a line command (psql) with the supplied password without pausing the command, but this option is not available: psql --username=root --password=root my_bd < "script.sql" The pass only can be informed after execution, pausing the command: psql --username=root --password my_bd Yes, the --password option forces the server to request password authentication. What you need to do is create a password file and specify --no-password on your psql command. See: http://www.postgresql.org/docs/8.4/interactive/libpq-pgpass.html Regards, -- Mike Fowler Registered Linux user: 379787 -- 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 #5623: xml2 and uuid-ossp contribs fail to compile
On 18/08/10 14:55, Jens Wilke wrote: The following bug has been logged online: Bug reference: 5623 Logged by: Jens Wilke Email address: jens.wi...@affinitas.de PostgreSQL version: 9.0b4 Operating system: Debian GNU/Linux Lenny Description:xml2 and uuid-ossp contribs fail to compile Details: Hi, to compile xml2 this link was necessary: ln -s /usr/include/libxml2/libxml ../../src/include I can't comment on uuid-ossp, but your XML problem sounds to me like libxml2 wasn't installed correctly. What parameters did you pass to configure? Could you build postgres with xml support? As in: path/to/pgsql/src> ./configure --with-libxml path/to/pgsql/src> make && make check Regards, -- Mike Fowler Registered Linux user: 379787 -- 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 #5745: geometry bug?
On 10/11/10 10:08, Jin wrote: The following bug has been logged online: Bug reference: 5745 Logged by: Jin Email address: jind...@gmail.com PostgreSQL version: 8.4.5 Operating system: windows xp pro sp3 Description:geometry bug? Details: The distance of the horizontal lseg and the point on that is inaccurate. select point(1.0,1.0)<-> lseg'(0.0,0.0),(2.0,0.0)'; ↓ result 1.4142135623731 must be 1.0 P.S. I'm sorry about if it was already reported. Because I can't read English well. From my digging it appears that this is returning the distance between the first point in the line and the individual point. To get 1.0 you would be looking for the the distance between the midpoint of the line and the individual point which can be achieved with: SELECT POINT(1.0,1.0) <-> POINT(LSEG'(0.0,0.0),(2.0,0.0)'); Digging through the documentation I can't find anything that says which point should be used in the line for distance comparisons. So I would rephrase this bug as: The distance of the horizontal lseg and the point is calculated against the first point in the line. Should this be calculated against the midpoint of the line instead? Regards, -- Mike Fowler Registered Linux user: 379787 -- 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 #5859: XML result in line and column
On 01/02/11 15:20, Alexandre wrote:
The following bug has been logged online:
Bug reference: 5859
Logged by: Alexandre
Email address: ultr...@gmail.com
PostgreSQL version: 8.4.7
Operating system: Windows 7
Description:XML result in line and column
Details:
The name of the xml tag is not being updated, becoming the first name
registry for all. Here is example:
Create table AUDITORIA_ANTERIOR
(
SEQUENCIA Serial NOT NULL,
SEQUENCIA_AUDITORIA Integer NOT NULL,
REGISTRO Text NOT NULL,
primary key (SEQUENCIA,SEQUENCIA_AUDITORIA)
);
insert into auditoria_anterior (sequencia_auditoria, registro)
values (1, '
123456789011FJOAO DA
SILVA ')
SELECT * FROM
xpath_table('sequencia',
'registro',
'auditoria_anterior',
'name(/ROOT/CLIENTES/*)|/ROOT/CLIENTES/*',
'sequencia = 1')
AS t(sequencia integer, coluna text, valor text)
--Incorrect result---
sequencia colunavalor
integer text text
--
1 CGC_CPF_CLIENTE 12345678901
1 CGC_CPF_CLIENTE 1
1 CGC_CPF_CLIENTE F
1 CGC_CPF_CLIENTE JOAO DA SILVA
Yep, I can duplicate this under Linux. However this is not a bug in
xpath_table. The problem is your XPath statement - the function name()
always returns the element name of the first element in a list. See
http://www.w3.org/TR/xpath/#section-Node-Set-Functions for details.
Unfortunately the only way to achieve what you want with with XPath 2.0
or XQuery, but libxslt (the underlying library executing the XPath) does
not and does not plan to support XPath 2.0 and PostgreSQL won't support
XQuery any time soon
(http://wiki.postgresql.org/wiki/XML_Support#Future_Projects).
Regards,
--
Mike Fowler
Registered Linux user: 379787
--
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 #5974: UNION construct type cast gives poor error message
On 13/04/11 19:32, Tom Lane wrote: "Jeff Wu" writes: The UNION construct (as noted on this page: http://www.postgresql.org/docs/9.0/static/typeconv-union-case.html) will cast unknown types to TEXT, however, if you try to do three or more UNIONs the order in which the UNIONs are executed will cause some columns to be cast to TEXT prematurely. The result is a type mismatch error. Or maybe we could find out that some other products do it like that despite what the spec says? regards, tom lane I happen to have a MS SQLServer 2008 instance at work as well as a MySQL 5.1 and an Oracle 10g. With the query: SELECT 1,null,null UNION SELECT 2,3,null UNION SELECT 3,null,4 In MS SQLServer I get (NB: no column headings): -- -- 1 | | 2 | 3 | 3 | | 4 In MySQL I get: 1 | NULL | NULL 1 | | 2 | 3 | 3 | | 4 In Oracle I get a delicious error message: Error: ORA-00923: FROM keyword not found where expected SQLState: 42000 ErrorCode: 923 Position: 19 Regards, -- Mike Fowler Registered Linux user: 379787 -- 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 #5974: UNION construct type cast gives poor error message
On 14/04/11 17:05, Kevin Grittner wrote:
SELECT 1,null,null FROM DUAL
UNION
SELECT 2,3,null FROM DUAL
UNION
SELECT 3,null,4 FROM DUAL
Sadly I can't profess to knowing Oracle, however if I run the query as
suggested I get:
1 | NULL | NULL
1 | |
2 | 3 |
3 | | 4
So to summarise, Oracle and PostgreSQL need minor tweaks to run cleanly
and SQLServer and MySQL do not. Given that the change for PostgreSQL is
so minor, I vote for changing the error message as Jeff suggests in the
interim to help users while the standards argument continues. Patch
attached.
Regards,
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/parser/parse_coerce.c
--- b/src/backend/parser/parse_coerce.c
***
*** 1161,1167 select_common_type(ParseState *pstate, List *exprs, const char *context,
(errcode(ERRCODE_DATATYPE_MISMATCH),
/*--
translator: first %s is name of a SQL construct, eg CASE */
! errmsg("%s types %s and %s cannot be matched",
context,
format_type_be(ptype),
format_type_be(ntype)),
--- 1161,1167
(errcode(ERRCODE_DATATYPE_MISMATCH),
/*--
translator: first %s is name of a SQL construct, eg CASE */
! errmsg("%s types %s and %s cannot be matched. HINT: Postgres casts unknown types to TEXT by default.",
context,
format_type_be(ptype),
format_type_be(ntype)),
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
