On Mon, Nov 08, 2010 at 12:55:22PM -0300, Alvaro Herrera wrote:
Excerpts from Charles Pritchard's message of sáb nov 06 23:20:13 -0300 2010:
Simple async sql sub-set (the spec in trouble):
http://dev.w3.org/html5/webdatabase/
This is insane. This spec allows the server to run arbitrary
On Sat, Oct 30, 2010 at 01:01:44PM -0400, Tom Lane wrote:
marcin mank marcin.m...@gmail.com writes:
This is what boost does:
http://www.systomath.com/include/Boost-1_34/doc/html/boost/hash_combine.html
Hmm. I am reminded of Knuth's famous dictum: never generate random
numbers with a
On Tue, Jul 20, 2010 at 09:57:06AM +0400, Zotov wrote:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
WHERE (d1.ID=234409763) or (d2.ID=234409763)
You could try rewriting it to:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
JOIN DocPrimary d2 ON
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
I don't know about a *good* idea, but here's the one I've got.
1. Make a whitelist. This is what needs to work in order for a
language to be a fully functional trusted PL.
Well, I pretty
On Mon, Nov 09, 2009 at 10:01:53AM -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
One idea is to take a copy of the state datum after each row. Then,
instead of initializing the aggregate from scratch, you can roll back
to an earlier copied state. It
On Fri, Nov 06, 2009 at 07:09:46PM -0800, David E. Wheeler wrote:
On Nov 6, 2009, at 6:57 PM, Tom Lane wrote:
If we do that, presumably the per-function syntax would be
#variable_conflict variable_first
and so on, which is clear enough but might be thought a bit verbose
for something
On Tue, Oct 27, 2009 at 08:30:16AM -0400, Andrew Dunstan wrote:
If someone is going to work on a JS engine for PostgreSQL (which I think
is a good idea, actually) I want them to work on one that is likely to
succeed.
The project (at the moment) just seems to be a set of pointers to code
I
On Fri, Sep 25, 2009 at 09:29:24AM +0300, Peter Eisentraut wrote:
On Thu, 2009-09-24 at 20:36 -0400, Tom Lane wrote:
BTW, are port numbers still limited to 16 bits in IPv6?
Port numbers are in TCP, not in IP.
I'd checked that it should work with IPv6, but I hadn't realized that
it was
On Thu, Sep 24, 2009 at 07:57:55PM +0100, Sam Mason wrote:
postg...@sussy:/root createuser -D -p ricky
I don't think you want to be passing -p here; it's saying to use
ricky as the port number, which fails (sounds like a bug if it doesn't
complain about this) giving a port number of zero
On Mon, Sep 14, 2009 at 11:20:59PM -0400, Tom Lane wrote:
There is some moderately interesting reading material in section
4.17.4 Domain constraints of SQL:2008.
Not sure where to look for a copy of that, nor any particularly helpful
links :(
In particular, it appears to
me that the standard
On Tue, Sep 15, 2009 at 05:13:21AM +0100, Andrew Gierth wrote:
But there's a kicker: in Subclause 6.12, cast specification, in the
General Rules is:
a) If the cast operand specifies NULL, then the result of CS is
the null value and no further General Rules of this Subclause
seems like a good
feature as well. Although it gives me the feeling that domains are more
and more like a mis-designed feature.
Sam == Sam Mason s...@samason.me.uk writes:
Sam The NOT NULL constraint feels wrong as well,
I think that's just another example of Tom's initial comment about how
On Fri, Sep 11, 2009 at 12:59:04PM -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I'm only proposing parse-time changes for conditional
expressions -- the CASE predicate and its abbreviations.
No, you are not; you are proposing run-time changes, specifically the
On Fri, Sep 11, 2009 at 06:24:22PM +0100, Sam Mason wrote:
One thing I've just realized these discussions have pointed out is
that PG isn't doing the correct thing all the time with types. When
is it ever valid to see an unknown after type checking? AFAICT, it
shouldn't ever appear and hence
On Fri, Sep 11, 2009 at 12:26:45PM -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
if that weren't true then we wouldn't be arguing about whether
COALESCE is wrong.
Yeah, I am. When you have queries built based on which fields on a
QBE window are filled by a user, it's
, NULL) OR ...)
Right. The only real way to fix that is to propagate the later
discovery that type 'date' would be preferred back to the inputs of the
COALESCE, which is what Sam Mason has been on about (IIUC).
Yup; sounds right. The fact that the inputs to COALESCE here are just
simple NULL
On Fri, Sep 11, 2009 at 12:41:21PM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
what you you want is full type-inference as it's only that which
will allow you to track back up the layers and assign consistent
types to arbitrary expressions like the above.
Well
On Wed, Sep 09, 2009 at 03:23:52PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
What we need is a system where base types are represented
by an OID, but derived types (list and functional types) are built up
using type constructors that take other types as arguments.
On Wed, Sep 09, 2009 at 10:25:34AM -0400, Tom Lane wrote:
Now admittedly there's probably not any major technical obstacle to
making a runtime conversion happen --- it's merely delayed invocation of
the destination type's input function. But I find it really ugly from a
theoretical point of
On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I wasn't suggesting adding a lot more testing of things that
we're already testing. I was assuming that we would craft the
additional tests to hit areas that we are not now covering
On Mon, Aug 24, 2009 at 09:12:07AM -0700, David Fetter wrote:
shac...@shackle:5432=# SELECT now() + '90';
?column?
---
2009-09-03 19:03:43.195514-07
(1 row)
shac...@shackle:5432=# SELECT now() - '90';
ERROR: date/time field
On Mon, Aug 24, 2009 at 01:41:28PM -0400, Tom Lane wrote:
The real problem with this is that all the
good candidates for the reserved word are things people are probably
already using as aliases, so we'd have a large risk of breaking existing
queries. We could avoid that with a sufficiently
On Mon, Aug 24, 2009 at 07:07:13AM -0700, David Fetter wrote:
These next two lines are a teensy bit baroque. Is there some
significant speed increase that would justify them?
Just noticed with your revised code that the following check:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews
On Mon, Aug 24, 2009 at 06:59:38PM +0100, Sam Mason wrote:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
if (x == 0.0)
return 0.0;
else {
yx = y/x;
is preventing a divide by zero on the line above. So it's not a
performance hack, it's
Hi,
The docs for the function random() currently say:
random value between 0.0 and 1.0, inclusive
this isn't a particularly useful invariant, what the code actually does
(and is commented as doing) is much more useful. Any chance of changing
it to something like:
--- doc/src/sgml/func.sgml~
On Sun, Aug 16, 2009 at 03:57:08PM +0300, Peter Eisentraut wrote:
On 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote:
SQL is not Lisp. Simple is good. I didn't think Peter was really very
serious.
Well, I don't know if we really need to call it lambda, but I fully
expect to be able to
On Sun, Aug 16, 2009 at 03:57:23PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
The docs for the function random() currently say:
random value between 0.0 and 1.0, inclusive
Yeah, it looks like Bruce changed this back in 8.2 and failed to fix
the documentation to match
On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote:
Nitpicking dept, I think I prefer:
DO [ [LANGUAGE] language] $$ ... $$;
DO plperl $$ ... $$;
DO language plpython $$ ... $$;
language is optional and defaults to plpgsql.
Yup, sounds nicer. The less globals the better!
On Sun, Aug 16, 2009 at 02:15:39AM +0300, Peter Eisentraut wrote:
On 2009-08-15 at 23:31 +0100, Sam Mason wrote:
Next all you need is to be able to PREPARE them (and somehow access the
parameters from execute) and you'll have nice local functions. :)
Yeah, rather than just making up some
On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high on my astonishment scale that a
COALESCE of two untyped NULLs (or
On Fri, Aug 07, 2009 at 10:36:39AM +0200, Pierre Frrrdddric Caillaud wrote:
Also, about compressed NTFS : it can give you disk-full errors on read().
While this may appear stupid, it is in fact very good.
Is this not just because they've broken the semantics of read?
As a side note, I have
On Fri, Aug 07, 2009 at 10:33:33AM +0100, Greg Stark wrote:
2009/8/7 Pierre Frédéric Caillaud li...@peufeu.com:
Also, about compressed NTFS : it can give you disk-full errors on read().
I suspect it's unavoidable for similar reasons to the problems
Postgres faces. When you issue a read()
On Fri, Aug 07, 2009 at 11:49:46AM +0100, Greg Stark wrote:
On Fri, Aug 7, 2009 at 11:29 AM, Sam Masons...@samason.me.uk wrote:
When you choose a compression algorithm you know how much space a worst
case compression will take (i.e. lzo takes up to 8% more for a 4kB block
size). This space
On Fri, Aug 07, 2009 at 12:59:57PM +0100, Greg Stark wrote:
On Fri, Aug 7, 2009 at 12:48 PM, Sam Masons...@samason.me.uk wrote:
Well most users want compression for the space savings. So running out
of space sooner than without compression when most of the space is
actually unused would
On Fri, Aug 07, 2009 at 03:29:44PM +0200, Pierre Frrrdddric Caillaud wrote:
vmstat output :
Sorry, I don't know enough of PGs internals to suggest anything here,
but iostat may give you more details as to what's going on.
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list
On Fri, Aug 07, 2009 at 04:17:18PM +0200, Pierre Frrrdddric Caillaud wrote:
I'm answering my own question : at the beginning of the run, postgres
creates a 800MB temporary file, then it fills the table, then deletes the
temp file.
Is this because I use generate_series to fill the test
On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
We have two points with a finite separation in the x axis.
Postgres thinks they are not the
On Fri, Aug 07, 2009 at 10:19:20AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
What do people do when testing this? I think I'd look to something
like Student's t-test to check for statistical significance. My
working would go something like:
I assume
On Fri, Aug 07, 2009 at 10:29:27AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
points in PG [..] don't
arbitrarily go jumping off millions of miles away or being annihilated
by their anti-particle just because it's possible.
It was definitely
On Fri, Aug 07, 2009 at 10:39:19AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
Yes, all that sounds as though you've got it.
Thanks. I read through it carefully a few times, but I was still only
80% confident that I had it more-or-less right. ;-)
And which method
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
I would agree with Paul that EPSILON is a hack and probably should be
removed.
It's a hack but it's dealing with an extremely real problem, namely
the built-in inaccuracy of floating-point
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
Sorry, I'm struggling to parse that. I think it's all the double
negatives. Are you saying that HYPOT() should really return zero when
it's currently giving back would be FPzero?
No, I'm
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
No, I'm worried about code that supposes that it can divide by (x - y)
after testing that FPeq(x,y) is not true. point_sl() for instance
On Fri, Aug 07, 2009 at 07:48:15PM +0100, Greg Stark wrote:
On Fri, Aug 7, 2009 at 7:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Underflow. x!=y does not imply (x-y) != 0, if x and y are sufficiently
small and close together. The difference could underflow to zero.
Actually I don't think
On Fri, Aug 07, 2009 at 02:08:21PM -0500, Kevin Grittner wrote:
With the 20 samples from that last round of tests, the answer (rounded
to the nearest percent) is 60%, so probably noise is a good summary.
Combined with the 12 samples from earlier comparable runs with the
prior version of the
On Fri, Aug 07, 2009 at 03:18:54PM -0400, Robert Haas wrote:
On Fri, Aug 7, 2009 at 3:08 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
With the 20 samples from that last round of tests, the answer (rounded
to the nearest percent) is 60%, so probably noise is a good summary.
So
On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Peter pointed out upthread that the SQL standard already calls out some
things that should be available in this way --- has anyone studied that
yet?
yes - it's part of GET DIAGNOSTICS
On Thu, Aug 06, 2009 at 11:41:55AM +0200, Pavel Stehule wrote:
typically in SQL/PSM (stored procedures - look on GET DIAGNOSTICS
statement in plpgsql doc), maybe in ecpg. Other's environments raise
exception - so you can get some data from exception or from special
structures related to
On Tue, Aug 04, 2009 at 01:12:10PM -0400, Alvaro Herrera wrote:
First we need several new error message fields: table name, function
name, constraint name, and so on. One possible way to go about this
would be to give each new field its own start letter (see
On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
What are people doing with parsing error messages for column names for
datatype mismatches? I can't imagine any of my code being able to do
anything sensible in such a case. If it's things like people giving
dates to the
On Wed, Aug 05, 2009 at 09:30:02AM -0500, Kevin Grittner wrote:
Anyway, the upshot is -- I think that it would be beneficial to allow,
to the extent we can confirm it's not a violation of any applicable
standard, a user-defined SQLSTATE to be associated with a constraint.
I also think that it
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
Not sure if overloading SQLSTATE is the right way of doing this is
it? It already has things like 23514 for a check violation and any
other client code relying in this would break
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
From the spec:
The character string value returned in an SQLSTATE parameter
comprises a 2-character class value followed by a 3-character subclass
value, each with an implementation-defined character set that has a
one-octet
On Mon, Aug 03, 2009 at 10:03:47AM -0500, Kevin Grittner wrote:
That's about 0.52% slower with the patch. Because there was over 10%
variation in the numbers with the patch, I tried leaving out the four
highest outliers on both, in case it was the result of some other
activity on the system
On Tue, Aug 04, 2009 at 10:45:52AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
t = 0.54 ((avg1 - avg2) / (stddev * sqrt(2/samples)))
We then have to choose how certain we want to be that they're actually
different, 90% is a reasonably easy level to hit (i.e. one
On Mon, Jul 27, 2009 at 01:53:07PM -0400, Chris Browne wrote:
s...@samason.me.uk (Sam Mason) writes:
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
Robert Haas wrote:
Sam Mason wrote:
The traditional approach would be to maintain multiple physically
separate databases; in this setup it's obvious that when you perform a
backup of one of these databases you're only seeing
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of security context with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe them in the
On Sun, Jul 26, 2009 at 12:49:32PM -0500, Kevin Grittner wrote:
Codd, E.F. (1990). The Relational Model for Database Management
(Version 2 ed.). Addison Wesley Publishing Company.
ISBN 0-201-14192-2.
Looks as though I've got some reading to do then--somewhat annoying that
only second hand
On Sun, Jul 26, 2009 at 03:46:19PM -0700, David E. Wheeler wrote:
And something I'd like to be able to handle in a while loop, as I'm
actually fetching one row at a time from two cursors and need to be
able to tell when I've reached the end of a cursor.
I'm sure I'm missing something
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION show_customers
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
Sorry for using the undefined terminology.
I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is understandable/usable by
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
There had better still be superusers. Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 4:27 PM, Sam Masons...@samason.me.uk wrote:
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the power they currently do.
It's been billed that way, but it's not
On Sat, Jul 25, 2009 at 11:42:04AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
In this dichotomy a NULL is most definitely a value and with my
current experience I don't understand the distinction you're trying
to draw.
There can be a place where a value *could* go
On Fri, Jul 24, 2009 at 09:31:13AM -0400, Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
So it is wrong to talk about ROW(NULL, NULL) being NULL. It doesn't
have the property of being NULL or not NULL, because it is a composite
value. ROW(NULL, NULL) IS NULL returns true, but that
On Fri, Jul 24, 2009 at 12:30:39PM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
The fact that it happens to be a NULL *value* in one case
Well, according to Codd (and I tend to go with him on this) there is
no such thing. NULL is a way to flag a place where a value
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
- SECURITY_LABEL =
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a row
On Sun, Jul 19, 2009 at 10:13:35PM +0800, Xin Wang wrote:
My research project is based on PostgreSQL. I want to get the
Post-Schema-Validation-Infoset (PSVI) of an XML document being
stored. However, the current libxml2 library does not support PSVI at
all. So I have to use the Xerces C++
On Mon, Jul 13, 2009 at 07:06:40PM +0100, Simon Riggs wrote:
On Mon, 2009-07-13 at 13:33 -0400, Tom Lane wrote:
It's hard to believe
this sort of case comes up often enough to justify the cycles that would
be expended (on *every* join query) to try to recognize it.
Yeh, damn ORMs seem to
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
Sam Mason s...@samason.me.uk wrote:
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need
On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
regression=# select '999'::interval second;
The correct interpretation of the input value is certainly 999 seconds.
Agreed; silent truncation like this is confusing and will lead to
unnecessary bugs in users' code.
the attached patch
On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote:
As I said earlier I doubt pop or delete is ever going to actually
be what you want. I suspect you're far more likely to want to restore
it to what it was before you started altering it.
As support I'll point out this is what our C
On Thu, May 28, 2009 at 09:06:14PM -0400, Andrew Dunstan wrote:
Does Python 3 have some sort of usable sandbox that would mean we could
have a trusted plpython?
Not sure if people are aware of object-capability based approaches to
security. A guy called Tav has come up with some code that
On Thu, May 21, 2009 at 12:26:08PM -0400, Tom Lane wrote:
I'd envision it
as an extra column in pg_attribute, and it would work for any column(s).
There's nothing to be gained by restricting it.
Yes, when I said first I meant the only thing that needs to be stored
is the first default value
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
I don't think this is because of the NULL bitmap. PG just never needs
On Mon, Apr 27, 2009 at 09:24:55AM +0100, Sam Halliday wrote:
Not looking for a Windows solution. Must be cross platform and work
for headless machines, laptops and desktops. Encrypted drive solutions
fall short of these requirements. Other considerations which rule out
encrypted drives
On Mon, Apr 27, 2009 at 07:03:32AM +1200, Andrej wrote:
2009/4/26 Sam Halliday sam.halli...@gmail.com:
I'm still talking about theft of machines (particularly laptops) as that is
a major threat. One need only read the British newspapers to discover story
after story of articles where
On Thu, Apr 16, 2009 at 12:08:37PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
I've failed to keep up with the discussion so I'm not sure where this
conversation has got to! Is the consensus for 8.4 to enable SQL2003
style Ulit escaped literals if and only
On Fri, Apr 17, 2009 at 10:15:57AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
Just noticed that the spec only supports four hex digits;
Better read it again.
You're right of course. My ability to read patches seems not to be very
good.
--
Sam http://samason.me.uk
On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
Btw, is there any good reason why we don't reject \000, \x00
in text strings?
Why forbid nulls in text strings?
As far as I know, PG assumes, like most C
On Wed, Apr 15, 2009 at 11:19:42PM +0300, Marko Kreen wrote:
On 4/15/09, Tom Lane t...@sss.pgh.pa.us wrote:
Given Martijn's complaint about more-than-16-bit code points, I think
the \u proposal is not mature enough to go into 8.4. We can think
about some version of that later, if there's
On Thu, Apr 16, 2009 at 02:47:20PM +0300, Marko Kreen wrote:
On 4/16/09, Sam Mason s...@samason.me.uk wrote:
Microsoft have also gone this way in C#, named code points are not
supported however.
And it handles also non-BMP codepoints with \u escape similarly:
http://en.csharp
On Thu, Apr 16, 2009 at 10:54:16AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
I'd never heard of UTF-16 surrogate pairs before this discussion and
hence didn't realise that it's valid to have a surrogate pair in place
of a single code point. The docs say that D800 DF02
On Thu, Apr 16, 2009 at 06:34:06PM +0300, Marko Kreen wrote:
Which hints that you can aswell enter the pairs directly: \uxx\uxx.
If I'd be language designer, I would not see any reason to disallow it.
And anyway, at least mono seems to support it:
using System;
public class HelloWorld {
On Thu, Apr 16, 2009 at 08:48:58PM +0300, Marko Kreen wrote:
Seems I'm bad at communicating in english,
I hope you're not saying this because of my misunderstandings!
so here is C variant of
my proposal to bring \u escaping into extended strings. Reasons:
- More people are familiar with
On Thu, Apr 16, 2009 at 03:04:37PM -0400, Andrew Dunstan wrote:
Sam Mason wrote:
Are you sure that this handling of surrogates is correct? The best
answer I've managed to find on the Unicode consortium's site is:
http://unicode.org/faq/utf_bom.html#utf16-7
it says
On Tue, Apr 14, 2009 at 04:01:48PM +0300, Peter Eisentraut wrote:
On Saturday 11 April 2009 18:20:47 Sam Mason wrote:
I can't see much support in the other database engines; searched for
Oracle, MS-SQL, DB2 and Firebird. MySQL has it planned for 7.1, so not
for a while.
DB2 supports
On Fri, Apr 10, 2009 at 05:54:25PM -0400, Tom Lane wrote:
It gets worse though: I have seldom seen such a badly designed piece of
syntax as the Unicode string syntax --- see
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
I think we need to
On Sat, Apr 11, 2009 at 11:13:59AM -0400, Tom Lane wrote:
My own take on it is that actually I'd prefer one command for all of
these. If I say \df sum it would be good if the output included the
sum() aggregates; the reason being that I might be wondering if I can
create a plain function
On Wed, Apr 08, 2009 at 08:16:52PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Anyway, I revised this a bit and applied to HEAD.
I've not tested; but your changes look as though they will break:
SELECT 'Infinity
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT 'NaN '::float8;
SELECT '+NaN'::float8;
SELECT '-NaN'::float8;
Well, the +- part must be an artifact of your strtod
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
IIRC, the explicit support for leading/trailing spaces is something that
we added in float8in long after numeric_in was written, and I
Hi,
I've just noticed that the NUMERIC input function special cases NaN
values differently to the floating point input functions. For example
the following are all accepted (on my system anyway):
SELECT 'NaN'::float8;
SELECT ' NaN'::float8;
SELECT 'NaN '::float8;
SELECT '+NaN'::float8;
On Thu, Apr 02, 2009 at 02:04:41PM -0400, Tom Lane wrote:
A correct fix
outside-the-function would look more like
case when str = '' then '{}'::text[] else string_to_array(str, ',') end
which should correctly yield NULL for NULL input and an empty array
for empty input. Similarly, if
[ oops, forgot to send this to -hackers before ]
On Tue, Mar 31, 2009 at 05:08:45PM +0100, Greg Stark wrote:
Both interpretations are clearly consistent but it depends on whether
you think it's a bunch of text strings concatenated together or if
it's a list of objects.
The example of
On Wed, Apr 01, 2009 at 10:23:18AM -0700, David E. Wheeler wrote:
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the
On Wed, Apr 01, 2009 at 07:40:16PM +0100, Greg Stark wrote:
The existing behaviour of returning NULL is the only consistent
choice since the correct value is unknown. And one could argue that
it's easier to replace NULL with the correct value if the programmer
knows using coalesce than it is
1 - 100 of 184 matches
Mail list logo
