On Tue, Sep 08, 2009 at 11:37:14PM -0400, Tom Lane wrote:
I wrote:
David Fetter da...@fetter.org writes:
WITH RECURSIVE t(j) AS (
WITH RECURSIVE s(i) AS (
VALUES (1)
UNION ALL
SELECT i+1 FROM s WHERE i 10
) SELECT i AS j FROM s
UNION ALL
SELECT
On Tue, Sep 8, 2009 at 1:07 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Tom Lane wrote:
Michael Gould mgo...@intermodalsoftwaresolutions.net writes:
It would be nice if we could enable and disable column and table
constraints. I believe that you can do this in Oracle but this is
On Tue, Sep 08, 2009 at 06:28:36PM -0700, James Pye wrote:
On Sep 8, 2009, at 5:33 PM, Itagaki Takahiro wrote:
WHEN clause in other times [1][2][3]. (All of them use WHEN for
the syntax; that's why I proposed WHEN but not WHERE.)
Well, looks like WHEN is, or is going to be standard:
You can see strange error on gothic moth (Solaris Nevada, SunStudio 12,
Sparc):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-09-08%2019:06:01
= pgsql.19404/contrib/tsearch2/regression.diffs
===
*** ./expected/tsearch2.out Tue Sep 8
Dne 5.09.09 00:09, Josh Berkus napsal(a):
On 9/4/09 2:49 PM, Tom Lane wrote:
Wasn't anybody paying attention?
Apparently nobody is using it on other platforms. I know I'm not.
I think that buildfarm members can enable it for supported platform. I
already did it for my machine.
ff-bg is doubled in the output and space is missing. It smells like
compiler bug. I will look closer on it next week, but can somebody point
me place in the code where I shall start?
Play around HLIDSKIP macros. Parser returns hyphen word with several lexemes, in
example above: 'ff-bg', 'ff',
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means anything at all.
Yes, for the
On Thu, 2009-09-03 at 10:35 +0200, Ľubomír Varga wrote:
Hi.
I hope, that this is right mailing list.
SELECT date, value FROM t_event
WHERE t_event.id in (SELECT id FROM t_event
WHERE date '2009-08-25'
ORDER BY date DESC LIMIT 1)
ORDER BY date;
On Tue, 2009-09-08 at 13:18 -0500, Kevin Grittner wrote:
As a quick sample of something which I believe implements the correct
semantics for COALESCE and NULLIF, see the functions below.
You might want to show before and after, so it's clear what you are
suggesting to change.
--
Sent via
Peter Eisentraut wrote:
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means
On Thu, 2009-09-03 at 20:45 -0400, Josh Williams wrote:
The patch adds two new functions to the backend, pg_get_owner_object
and
pg_get_owner_column. These look up the requested object in the
pg_depend table, looking for an 'a' type dependency to another
relation,
and resolve either the
On Wed, 2009-09-09 at 07:47 -0400, Alvaro Herrera wrote:
Peter Eisentraut wrote:
On Tue, 2009-09-08 at 10:23 -0700, David E. Wheeler wrote:
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same
Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2009-09-08 at 13:18 -0500, Kevin Grittner wrote:
As a quick sample of something which I believe implements the
correct semantics for COALESCE and NULLIF, see the functions below.
You might want to show before and after, so it's clear what you
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two somewhat orthogonal issues:
1. Is a completely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello
The origin of this petition is an error produced today by a user on one
of our systems. Because of this error many users lost access to their
databases.
Problem:
-
If you define in pg_hba.conf a database or a user value with 'ALL'
2009/9/9 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two somewhat
Rafael Martinez wrote:
Or throw an error saying 'ALL' is not a valid value and *not* reload the
pg_hba.conf file.
But it's not invalid. It would designate a database or user named ALL.
That might be a silly thing to do, but that's another question.
cheers
andrew
--
Sent via
Hello
I thing so there are lot of aggregates based on generating array. We
have fast array_agg function, but we cannot be same effective with
custom aggregates. So my proposal is creating some new kind of
aggregates, that are based on arrays. The primary goal is getting same
speed as array_agg
Rafael Martinez wrote:
Problem:
-
If you define in pg_hba.conf a database or a user value with 'ALL'
instead of 'all', you will lose access to *all* databases involved. The
reload process will not report anything about 'ALL' been an invalid
value and the new pg_hba.conf will be
Andrew Dunstan wrote:
Rafael Martinez wrote:
Or throw an error saying 'ALL' is not a valid value and *not* reload the
pg_hba.conf file.
But it's not invalid. It would designate a database or user named
ALL. That might be a silly thing to do, but that's another
question.
Surely if you
Alvaro Herrera alvhe...@commandprompt.com wrote:
Both DB2 and Oracle have an ENFORCE setting for constraints, and a
MySQL blog hinted some time ago that it might be in SQL 201x.
If I remember correctly, Sybase never checks the existing data when
you add a constraint of any type (except for a
Kevin Grittner kevin.gritt...@wicourts.gov writes:
OK. The only time it would be different from current behavior is when
all parameters are of unknown type -- the result would be unknown
rather than text:
The difficulty with that is that it implies eventually having to coerce
from unknown to
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Rafael Martinez wrote:
Or throw an error saying 'ALL' is not a valid value and *not* reload the
pg_hba.conf file.
But it's not invalid. It would designate a database or user named
ALL. That might be a silly thing to do, but that's
Andrew Dunstan wrote:
Rafael Martinez wrote:
Or throw an error saying 'ALL' is not a valid value and *not* reload the
pg_hba.conf file.
But it's not invalid. It would designate a database or user named ALL.
That might be a silly thing to do, but that's another question.
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Surely if you want to designate a database named ALL you should use
quotes, same as if you wanted to designate a database named all (see my
other followup).
OK, but if we move to using pg_strcasecmp() that would be a
behaviour change, so I
Rafael Martinez wrote:
Shouldn't 'all' be a reserved word?, it has a special meaning when used
in pg_hba.conf.
No, it works fine with a line like this:
local all all md5
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Alvaro Herrera wrote:
Rafael Martinez wrote:
Shouldn't 'all' be a reserved word?, it has a special meaning when used
in pg_hba.conf.
No, it works fine with a line like this:
local all all md5
Ok, then all and ALL should be valid values but not all and ALL
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
It will affect any dbname or username in mixed or upper case, not just
ALL, won't it?
No, I am suggesting to change only the comparisons to the literals
all, sameuser, samegroup and samerole.
Hmm. These words are
Unicode escapes for extended strings.
On 4/16/09, Marko Kreen mark...@gmail.com wrote:
Reasons:
- More people are familiar with \u escaping, as it's standard
in Java/C#/Python, probably more..
- U strings will not work when stdstr=off.
Syntax:
\u - 16-bit value
On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote:
On Thu, 2009-09-03 at 20:45 -0400, Josh Williams wrote:
The patch adds two new functions to the backend, pg_get_owner_object
and
pg_get_owner_column. These look up the requested object in the
pg_depend table, looking for an 'a' type
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
1. Is a completely unconstrained argument type (ie any) of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT
NULL
tests, which might or might not be worth
On Sep 9, 2009, at 8:39 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there are two
Hello everyone,
I ran into a problem writing a program using libpq, and after postin on
a forum and asking it on the irc channel I was redirected here.
I'll try to keep it simple so you don't have to read to much to start:
The program is asynchronous using libev, using sockets and notifications
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
1. Is a completely unconstrained argument type (ie any) of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT
On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not necessarily
sane to give to PL authors. I'm willing to
Tom Lane wrote:
In an example like
create function foo (anyelement, anyelement2, anyelement2)
returns anyarray2
the second and third arguments would be tied to be of the same type,
and the result would be an array of that type; whereas the first
argument's type is unrelated.
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In order for this to work in general, we'd need FUNC_MAX_ARGS different
types, which is currently defined as 100 in
On Sep 9, 2009, at 10:15 AM, Tom Lane wrote:
In order for this to work in general, we'd need FUNC_MAX_ARGS
different
types, which is currently defined as 100 in our code.
But here, any would work perfectly fine, since there's no need for
any two arguments to be tied to each other or the
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not
David E. Wheeler da...@kineticode.com writes:
On Sep 9, 2009, at 10:15 AM, Tom Lane wrote:
But here, any would work perfectly fine, since there's no need for
any two arguments to be tied to each other or the result.
Well, only if you write your functions in C. I'd like to be able to
write
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In order for this to work in general, we'd need FUNC_MAX_ARGS different
types, which is
On Sep 9, 2009, at 10:17 AM, Tom Lane wrote:
Well, none, *if* it's defined to have exactly the same runtime
behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like anyelement
but not constrained to match any other
Alvaro Herrera alvhe...@commandprompt.com writes:
BTW does any match other pseudotypes? Would I be able to pass a
cstring into any? That would create a large security hole I think.
How so? 'Cause you can do that now with anyelement.
cstring is only a pseudotype for historical reasons,
On Sep 9, 2009, at 10:22 AM, Tom Lane wrote:
Well, only if you write your functions in C. I'd like to be able to
write sprintf() in PL/pgSQL. Or PL/Perl, for that matter.
I think you're confusing the point with a secondary issue, which is
what
access we provide to these pseudotypes in PLs.
David E. Wheeler da...@kineticode.com writes:
Yes, that sounds about right. Is that not basically what Alvaro was
looking for to start with? And is there an any array that could work
for variadic functions like sprintf(), as well?
Well, no, because arrays are inherently all the same
Maarten =?ISO-8859-1?Q?Foqu=E9?= maarten.fo...@edchq.com writes:
The program crashes on PQclear(resu) with the following:
*** glibc detected *** ./incident_relay: corrupted double-linked list:
0x09c459c8 ***
This looks like a memory-stomp type of bug. There's no reason to assume
that PQclear
2009/9/9 David E. Wheeler da...@kineticode.com:
On Sep 9, 2009, at 10:17 AM, Tom Lane wrote:
Well, none, *if* it's defined to have exactly the same runtime behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like
2009/9/9 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
Yes, that sounds about right. Is that not basically what Alvaro was
looking for to start with? And is there an any array that could work
for variadic functions like sprintf(), as well?
Well, no, because
Pavel Stehule escribió:
we are able to write sprintf(text, variadic any) returns text, but only in C
Hmm, should we provide that function in core?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
we are able to write sprintf(text, variadic any) returns text, but only in
C
Hmm, should we provide that function in core?
We should it, but I prefer some pgfoundry or contrib package. sprintf
is really far to SQL.
On Sep 9, 2009, at 4:44 AM, Peter Eisentraut wrote:
That's beginning to sound a bit like a generics feature. E.g.,
CREATE FUNCTION the_sameT(arg_a T, arg_b T) RETURNS bool AS $$
SELECT arg_a IS DISTINCT FROM arg_b;
$$;
mmm, yeah... ISTM that expansion in this area should probably head
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
we are able to write sprintf(text, variadic any) returns text, but only
in C
Hmm, should we provide that function in core?
We should it, but I prefer some pgfoundry or contrib
On Sep 8, 2009, at 10:48 AM, David Fetter wrote:
I'd like to see pseudo-types like ANYNUMERIC, and allow it to take an
array decorator, which would really help for math-ish functions. Not
sure where that fits in this discussion.
Perhaps typcategory could be leveraged here?
..Tho, if I
On Tue, Sep 08, 2009 at 11:37:14PM -0400, Tom Lane wrote:
I wrote:
David Fetter da...@fetter.org writes:
WITH RECURSIVE t(j) AS (
WITH RECURSIVE s(i) AS (
VALUES (1)
UNION ALL
SELECT i+1 FROM s WHERE i 10
) SELECT i AS j FROM s
UNION ALL
SELECT
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
BTW does any match other pseudotypes? Would I be able to pass a
cstring into any? That would create a large security hole I think.
How so? 'Cause you can do that now with anyelement.
Hmm, it doesn't seem to be allowed?
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
It will affect any dbname or username in mixed or upper case, not just
ALL, won't it?
No, I am suggesting to change only the comparisons to the literals
all, sameuser,
On mån, 2009-08-31 at 23:41 +0300, Peter Eisentraut wrote:
On sön, 2009-08-16 at 02:44 +0300, Peter Eisentraut wrote:
The remaining problem is that the patch loses domain checking on the
return types, because some paths no longer go through the data type's
input function. I have marked
David Fetter da...@fetter.org writes:
Should the outer query be able to reference further-in CTEs?
No, why would you expect that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Stephen Frost sfr...@snowman.net writes:
In general, I think that sounds like a good idea. At the same time, I
wouldn't be against changing the specific 'ALL' special-case comparison
in 8.4.2, using the argument that not many people have moved to it yet
and it's pretty far out there for an
On Wed, Sep 9, 2009 at 1:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In order for this to work in general, we'd need
On Wed, Sep 09, 2009 at 03:00:39PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Should the outer query be able to reference further-in CTEs?
No, why would you expect that?
No particular reason, I suppose. I'm not clear on what the standard
says about this.
Cheers,
David.
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.
This is SQL, not Haskell. What you suggest seems about two
David Fetter da...@fetter.org writes:
On Wed, Sep 09, 2009 at 03:00:39PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Should the outer query be able to reference further-in CTEs?
No, why would you expect that?
No particular reason, I suppose. I'm not clear on what the
Robert Haas escribió:
Really, I think we need a type system that doesn't try to represent
every type as a 32-bit integer. Right now, for example, there's no
reasonable way to write a function that takes another function as an
argument.
Function references would be neat -- I remember wanting
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
we are able to write sprintf(text, variadic any) returns text, but only
in C
Hmm, should we provide that function in core?
We
2009/9/9 Robert Haas robertmh...@gmail.com:
On Wed, Sep 9, 2009 at 1:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns text
In
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
I already published a pseudo-sprintf function in the wiki here:
http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
better, not just the same hacks.
I don't see any good reason that the function
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
I already published a pseudo-sprintf function in the wiki here:
http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
better, not just the same
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be ignored and missing columns
filled with NULL. The client wanting
On Wednesday 09 September 2009 14:11:41 Peter Eisentraut wrote:
On Thu, 2009-09-03 at 10:35 +0200, Ľubomír Varga wrote:
Hi.
I hope, that this is right mailing list.
SELECT date, value FROM t_event
WHERE t_event.id in (SELECT id FROM t_event
WHERE date '2009-08-25'
Tom Lane wrote:
As for the numerous occasions, maybe I've not been paying attention,
but I don't recall any ...
I don't know about numerous, but I've seen it in the spanish list; for
example:
http://archives.postgresql.org/pgsql-es-ayuda/2007-03/msg00901.php
--
Alvaro Herrera
On Wed, 2009-09-09 at 09:39 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Well, so far we've only seen use cases in this thread that either
already work or that are not well-defined. ;-)
Well, yeah, the question is can we extract a clear TODO item here.
I think there
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row.
BTW, one other thought about this: I think the historical reason for
COPY being strict about the number of incoming
On Wed, 2009-09-09 at 15:10 -0400, Robert Haas wrote:
On Wed, Sep 9, 2009 at 1:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another possible example is sprintf:
create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
returns
Hannu Krosing ha...@2ndquadrant.com writes:
maybe we could (re/ab)use parametrized types and define
anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
the number in parentheses
Yeah, that idea occurred to me too. The immediate practical problem is
that we don't store a
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row.
BTW, one other thought about this: I think the historical reason for
COPY being strict about
On 9/9/09 12:59 PM, Andrew Dunstan wrote:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be ignored and missing columns
filled with NULL. The client wanting
2009/9/9 Hannu Krosing ha...@krosing.net:
On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
I already published a pseudo-sprintf function in the wiki
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be ignored and missing columns
filled with NULL.
Josh Berkus j...@agliodbs.com wrote:
Would this just work on columns on the end, or would it work on the
basis of parsing the CSV header and matching columns?
While the former functionality would be relatively simple, I think
the
latter is what people really want.
It's been a while since
On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
2009/9/9 Alvaro Herrera alvhe...@commandprompt.com:
I already published a pseudo-sprintf function in the wiki here:
Josh Berkus wrote:
On 9/9/09 12:59 PM, Andrew Dunstan wrote:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be ignored and missing columns
filled with NULL.
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, 2009-09-09 at 16:34 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row.
BTW, one other thought about
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
Dann Corbit dcor...@connx.com wrote:
Kevin Grittner
It's been a while since I've had a need for something like this,
but of the copy features not currently available in PostgreSQL,
the two most useful are to read in only some of the defined
columns, and to output to a separate disk file
Dann Corbit wrote:
Perhaps something like SQL Server's BCP format files could be used.
http://support.microsoft.com/kb/67409
http://technet.microsoft.com/en-us/library/ms178129.aspx
http://www.nigelrivett.net/SQLTsql/BCP_quoted_CSV_Format_file.html
On Sep 9, 2009, at 2:36 PM, Alvaro Herrera wrote:
Robert Haas escribió:
Really, I think we need a type system that doesn't try to represent
every type as a 32-bit integer. Right now, for example, there's no
reasonable way to write a function that takes another function as an
argument.
On Wed, 2009-05-27 at 14:25 -0700, Caleb Welton wrote:
Yes, in Python = 2.4 there is the Decimal datatype.
However, unlike the other mappings employed by plpythonu, Decimal
requires an import statement to be in scope.
adding it as already-imported module should not be hard
I think that
Folks,
Elein Mustain mentioned this, and I came up with a short repro. The
SQL standard does not distinguish between what's available to
aggregates normally and in the windowing context. However...
SELECT count(DISTINCT i) FROM (VALUES (1),(2),(3),(1)) AS s(i);
count
---
3
(1 row)
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Hannu Krosing ha...@2ndquadrant.com writes:
anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
the number in parentheses
Yeah, that idea occurred to me too. The immediate practical problem is
that we don't store a typmod for
David Fetter da...@fetter.org writes:
SELECT count(DISTINCT i) OVER () FROM (VALUES (1),(2),(3),(1)) AS s(i);
ERROR: DISTINCT is not implemented for window functions
Which part of that message isn't clear to you?
Anyhow, I think it's a bug and needs back-patching.
Not implemented is not a
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be ignored and missing columns
filled with NULL. The client wanting this has wrestled with some
preprocessors to
On Wed, Sep 09, 2009 at 06:35:05PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
SELECT count(DISTINCT i) OVER () FROM (VALUES (1),(2),(3),(1)) AS s(i);
ERROR: DISTINCT is not implemented for window functions
Which part of that message isn't clear to you?
A bug that's
On Wed, Sep 9, 2009 at 4:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I have received a requirement for the ability to import ragged CSV
files, i.e. files that contain variable numbers of columns per row. The
requirement is that extra columns would be
David Fetter da...@fetter.org writes:
A bug that's documented in the source code is still a bug.
Sorry, but we are not going to define every unimplemented feature in
SQL:2008 as being a back-patchable bug fix candidate. As for the it's
not documented argument, I direct you to section 4.2.8,
Robert Haas wrote:
I agree that ignoring extra columns is a bad idea, but I don't even
like the idea of ignoring missing columns. It doesn't seem like a
good idea to take a spreadsheet and feed it into COPY without doing
any validation anyway, and this is the kind of thing that is trivial
to
On Wed, Sep 9, 2009 at 3:23 PM, Tom Lanet...@sss.pgh.pa.us 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
On Wed, Sep 9, 2009 at 7:41 PM, Andrew Dunstanand...@dunslane.net wrote:
Robert Haas wrote:
I agree that ignoring extra columns is a bad idea, but I don't even
like the idea of ignoring missing columns. It doesn't seem like a
good idea to take a spreadsheet and feed it into COPY without
On Wed, Sep 9, 2009 at 6:24 PM, David Fetterda...@fetter.org wrote:
Anyhow, I think it's a bug and needs back-patching.
I suspect if it were as easy as removing the error test it would have
been done already. Perhaps you'd care to submit a patch?
...Robert
--
Sent via pgsql-hackers mailing
1 - 100 of 116 matches
Mail list logo
