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 arb
On Sat, Oct 30, 2010 at 01:01:44PM -0400, Tom Lane wrote:
> marcin mank 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 method chosen at
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 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 much los
On Mon, Nov 09, 2009 at 10:01:53AM -0500, Tom Lane wrote:
> Heikki Linnakangas 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 doesn't always help, but mig
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 somet
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 b
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 doe
Explicitly ignoring NULL values in CAST expressions 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 writes:
> Sam> The NOT NULL constraint feels wrong as well,
On Tue, Sep 15, 2009 at 05:13:21AM +0100, Andrew Gierth wrote:
> But there's a kicker: in Subclause 6.12, , in the
> General Rules is:
>
> a) If the specifies NULL, then the result of CS is
> the null value and no further General Rules of this Subclause
> are applied.
>
> Th
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 sta
On Fri, Sep 11, 2009 at 12:41:21PM -0500, Kevin Grittner wrote:
> Sam Mason 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
> AND (somedate < COALESCE(NULL, 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
On Fri, Sep 11, 2009 at 12:26:45PM -0500, Kevin Grittner wrote:
> Tom Lane 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 not hard to
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, i
On Fri, Sep 11, 2009 at 12:59:04PM -0400, Tom Lane wrote:
> "Kevin Grittner" 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
> need to coerce un
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 o
On Wed, Sep 09, 2009 at 03:23:52PM -0400, Tom Lane wrote:
> Robert Haas 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.
>
> This is SQL,
On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote:
> Robert Haas 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 well. My
> > poi
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
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 Matthe
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 sufficientl
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 fie
On Sun, Aug 16, 2009 at 03:57:23PM -0400, Tom Lane wrote:
> Sam Mason 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 documen
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
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 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,
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 b
On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> "Kevin Grittner" writes:
> >>> Still, it rates pretty high on my astonishment scale that a
> >>> COALESCE of two untyped NULLs (or for that matter, any two values
> >>> of unknown type)
On Fri, Aug 07, 2009 at 03:18:54PM -0400, Robert Haas wrote:
> On Fri, Aug 7, 2009 at 3:08 PM, 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.
>
> So should we give up on
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 t
On Fri, Aug 07, 2009 at 07:48:15PM +0100, Greg Stark wrote:
> On Fri, Aug 7, 2009 at 7:13 PM, Tom Lane 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 subtraction ca
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
> Sam Mason 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 no
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
> Sam Mason 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 b
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
> Sam Mason 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 inacc
On Fri, Aug 07, 2009 at 10:39:19AM -0500, Kevin Grittner wrote:
> Sam Mason 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 w
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 becaus
On Fri, Aug 07, 2009 at 10:19:20AM -0500, Kevin Grittner wrote:
> Sam Mason 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 somet
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 no
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 t
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 12:59:57PM +0100, Greg Stark wrote:
> On Fri, Aug 7, 2009 at 12:48 PM, Sam Mason 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
> >> ac
On Fri, Aug 07, 2009 at 11:49:46AM +0100, Greg Stark wrote:
> On Fri, Aug 7, 2009 at 11:29 AM, Sam Mason 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).
On Fri, Aug 07, 2009 at 10:33:33AM +0100, Greg Stark wrote:
> 2009/8/7 Pierre Frédéric Caillaud :
> > 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() you have to f
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 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 env
On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
> 2009/8/5 Tom Lane :
> > 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 statement
>
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-oc
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
> Sam Mason 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 woul
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
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 t
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
> http://www.postgresql.org/docs/
On Tue, Aug 04, 2009 at 10:45:52AM -0400, Tom Lane wrote:
> Sam Mason 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
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 syste
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
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 obv
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 co
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 t
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
> >>bac
On Sat, Jul 25, 2009 at 11:42:04AM -0500, Kevin Grittner wrote:
> Sam Mason 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
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason 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 bille
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 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 any
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:
> >
&g
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,
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 Fri, Jul 24, 2009 at 12:30:39PM -0500, Kevin Grittner wrote:
> Sam Mason 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 wher
On Fri, Jul 24, 2009 at 09:31:13AM -0400, Tom Lane wrote:
> Brendan Jurd 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 is not t
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
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
> Sam Mason 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.
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 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
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 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 co
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 valu
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
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 driv
On Mon, Apr 27, 2009 at 07:03:32AM +1200, Andrej wrote:
> 2009/4/26 Sam Halliday :
> > 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 "sensitive information
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 mos
On Fri, Apr 17, 2009 at 10:15:57AM -0400, Tom Lane wrote:
> Sam Mason 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.
On Thu, Apr 16, 2009 at 12:08:37PM -0400, Tom Lane wrote:
> Sam Mason 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 U&
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/fa
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 wi
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 HelloWor
On Thu, Apr 16, 2009 at 10:54:16AM -0400, Tom Lane wrote:
> Sam Mason 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
On Thu, Apr 16, 2009 at 02:47:20PM +0300, Marko Kreen wrote:
> On 4/16/09, Sam Mason 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:
On Wed, Apr 15, 2009 at 11:19:42PM +0300, Marko Kreen wrote:
> On 4/15/09, Tom Lane 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 enough inte
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
>
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 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
On Wed, Apr 08, 2009 at 08:16:52PM -0400, Tom Lane wrote:
> Sam Mason 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 wi
On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
> Sam Mason 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 wa
On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > SELECT 'NaN'::float8;
> > SELECT ' NaN'::float8;
> > SELECT 'NaN '::float8;
> > SELECT '+NaN'::float8;
> > SELECT '-NaN':
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,
On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
> On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler
> wrote:
> > Well, I'd just point out that the return value of string_to_array() is
> > text[]. Thus, this is not a problem with string_to_array(), but a casting
> > problem from text[
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
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
1 - 100 of 184 matches
Mail list logo