Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
format will produce invalid YAML, for example:
explain (format yaml) select * from foo where str_val = 'a: b';
The problem in this case is that a colon followed by whitespace is not
allowed in an unquoted plain YAML string because
Craig Ringer writes:
>> - other products are happy to solve the DISTINCT restriction without
>> any hint as far as what the datatype really is
>
> ... and so is Pg. That's not the problem; Pg complains after resolving the
> SELECT DISTINCT, when it finds that it's trying to insert values of
Craig,
I know it's not what you want (Pg behaving how you expect out of the
box) but creating implicit casts to the desired types will resolve
your immediate issue. You still have to run some Pg-specific code, but
it can be restricted to your DDL where there's (presumably) already
plenty.
My
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dean Rasheed wrote:
...
> So the current code in escape_yaml() is inadequate for producing valid
> YAML. I think it would have to also consider at least the following
> characters as special "-" ":" "[" "]" "{" "}" "," "\"" "'"
> "|" "*"
"Greg Sabino Mullane" writes:
> The rules should be:
> Requires quoting only if the first character:
> & * ! | > ' " % @ ` #
> Same as above, but no quoting if the second character is "safe":
> - ? :
> Always requires quoting:
> ":" "#" aka ': ' ' #'
> Always requires quoting
Craig Ringer wrote:
> showing that your issue isn't actually with DISTINCT at all, but with Pg's
> unwillingness to *implicitly* cast a value of explict text type to another
> type.
Is there a way to make values of "undefined" type pass through the SELECT
DISTINCT filter (getting checked for un
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
...
> Egad ... this is supposed to be an easily machine-generatable format?
>
> If it's really as broken as the above suggests, I think we should
> rip it out while we still can.
Heh ... not like you to shrink from a challenge.
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane wrote:
> Tom Lane wrote:
> I don't think the above would be particularly hard to implement myself,
> but if it becomes a really big deal, we can certainly punt by simply
> quoting anything containing an indicator (the special characters above).
On Mon, Jun 7, 2010 at 10:30 AM, Andy Balholm wrote:
> Craig Ringer wrote:
>> showing that your issue isn't actually with DISTINCT at all, but with Pg's
>> unwillingness to *implicitly* cast a value of explict text type to another
>> type.
>
> Is there a way to make values of "undefined" type pa
Andy Balholm writes:
> Is there a way to make values of "undefined" type pass through the
> SELECT DISTINCT filter (getting checked for uniqueness) but remain
> "undefined"
No. What is your criterion for deciding that two values are distinct?
It's not possible to do that without imputing a data
Robert Haas wrote:
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane wrote:
Tom Lane wrote:
I don't think the above would be particularly hard to implement myself,
but if it becomes a really big deal, we can certainly punt by simply
quoting anything containing an indicator (the special
"Greg Sabino Mullane" writes:
> I don't think the above would be particularly hard to implement myself,
> but if it becomes a really big deal, we can certainly punt by simply
> quoting anything containing an indicator (the special characters above).
I would go with that. The quoting rules you
On Jun 7, 2010, at 7:53 AM, Tom Lane wrote:
> Andy Balholm writes:
>> Is there a way to make values of "undefined" type pass through the
>> SELECT DISTINCT filter (getting checked for uniqueness) but remain
>> "undefined"
>
> No. What is your criterion for deciding that two values are distinct?
On 7 June 2010 15:56, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> I don't think the above would be particularly hard to implement myself,
>> but if it becomes a really big deal, we can certainly punt by simply
>> quoting anything containing an indicator (the special characters above).
>
>
On Mon, Jun 7, 2010 at 3:52 PM, Robert Haas wrote:
>> Is there a way to make values of "undefined" type pass through the SELECT
>> DISTINCT filter (getting checked for uniqueness) but remain "undefined" if
>> all the values supplied for the column are "undefined"?
The concept of "uniqueness" de
* Tom Lane:
> Egad ... this is supposed to be an easily machine-generatable format?
Perhaps you could surround all strings with "" in the generator, and
escape all potentially special characters (which seems to include some
whitespace even in quoted strings, unfortunately)?
It has been claimed b
Florian Weimer wrote:
It has been claimed before that YAML is a superset of JSON, so why
can't the YAML folks use the existing JSON output instead?
Because JSON just crosses the line where it feels like there's so much
markup that people expect a tool is necessary to read it, which has
alw
Greg Smith writes:
> The complaints about YAML taking up too much vertical space are
> understandable, but completely opposite of what I care about. I can
> e-mail a customer a YAML plan and it will survive to the other side and
> even in a reply back to me. Whereas any non-trivial text forma
Tom Lane wrote:
This doesn't look amazingly unlike the current JSON output,
and to the extent that we have to add more quoting to it, it's
going to look even more like the JSON output.
I don't know about that; here's the JSON one:
EXPLAIN (FORMAT JSON) SELECT * FROM customers WHERE customer
The following bug has been logged online:
Bug reference: 5491
Logged by: Piergiorgio Buongiovanni
Email address: piergiorgio.buongiova...@netspa.it
PostgreSQL version: 8.4.3
Operating system: x86_64-redhat-linux-gnu
Description:Queries performing slowly
Details:
Her
The following bug has been logged online:
Bug reference: 5492
Logged by: Piergiorgio Buongiovanni
Email address: piergiorgio.buongiova...@netspa.it
PostgreSQL version: 8:4.3
Operating system: x86_64-redhat-linux-gnu
Description:Query performs slowly and sequence corru
On Mon, Jun 7, 2010 at 5:36 PM, Piergiorgio Buongiovanni
wrote:
> I reused the previous command to re-set the sequence value to the right one,
> but I see that the START value is now 59100. I reused the previous command
> another time and the START value is now 30440.
>
> I think this is a bug. I
On 7/06/2010 11:34 PM, Piergiorgio Buongiovanni wrote:
The following bug has been logged online:
Bug reference: 5491
Logged by: Piergiorgio Buongiovanni
Email address: piergiorgio.buongiova...@netspa.it
PostgreSQL version: 8.4.3
Operating system: x86_64-redhat-linux-gnu
Des
23 matches
Mail list logo
