On Tue, Sep 08, 2009 at 11:37:14PM -0400, Tom Lane wrote:
> I wrote:
> > David Fetter 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
> >>
On Tue, Sep 8, 2009 at 1:07 PM, Alvaro
Herrera wrote:
> Tom Lane wrote:
>> Michael Gould 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 very
>> > handy for testing stored procedures and other ext
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 standar
You can see strange error on gothic moth (Solaris Nevada, SunStudio 12,
Sparc):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=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, f
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
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 pg
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 t
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 th
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 con
Peter Eisentraut 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 are
> sugg
Peter Eisentraut 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 unconstrained arg
-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'
inst
2009/9/9 Tom Lane :
> Peter Eisentraut 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.
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 pgsql
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 has
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 b
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.
Sur
Alvaro Herrera 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 unique constraint or
pri
"Kevin Grittner" 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 something else, only at
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 questi
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,
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 Repl
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 al
Alvaro Herrera 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 effectively keywo
Unicode escapes for extended strings.
On 4/16/09, Marko Kreen 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
> \U -
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 dependency
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 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 i
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" 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
>> NULL tes
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 c
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 unr
Alvaro Herrera 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 our code.
But here, "an
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 re
"David E. Wheeler" 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 necessarily
>> sane t
"David E. Wheeler" 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 sprintf()
Tom Lane wrote:
> Alvaro Herrera 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
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 ar
Alvaro Herrera 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, anyway --- there's
nothing
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" 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 element type.
You co
Maarten =?ISO-8859-1?Q?Foqu=E9?= 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 is the cause; it's mo
2009/9/9 David E. Wheeler :
> 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
>> bu
2009/9/9 Tom Lane :
> "David E. Wheeler" 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 s
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 supp
2009/9/9 Alvaro Herrera :
> 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. What more, we kn
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_same(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
toward
Pavel Stehule escribió:
> 2009/9/9 Alvaro Herrera :
> > 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. spri
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 unders
On Tue, Sep 08, 2009 at 11:37:14PM -0400, Tom Lane wrote:
> I wrote:
> > David Fetter 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
> >>
Tom Lane wrote:
> Alvaro Herrera 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?
alvherre=# creat
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera 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
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 mark
David Fetter 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:
http://www.postgresql.org/mai
Stephen Frost 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 'ALL' database to
On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
> Alvaro Herrera 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, whic
On Wed, Sep 09, 2009 at 03:00:39PM -0400, Tom Lane wrote:
> David Fetter 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.
--
David Fet
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, not Haskell. What you suggest seems about two orders of
magnitude mor
David Fetter writes:
> On Wed, Sep 09, 2009 at 03:00:39PM -0400, Tom Lane wrote:
>> David Fetter 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
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 want
2009/9/9 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/9/9 Alvaro Herrera :
>> > 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 som
2009/9/9 Robert Haas :
> On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
>> Alvaro Herrera 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_M
Pavel Stehule escribió:
> 2009/9/9 Alvaro Herrera :
> > 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 needs to be far
2009/9/9 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/9/9 Alvaro Herrera :
>
>> > 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
Andrew Dunstan 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 this has wrestled
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 <
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 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
Andrew Dunstan 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 columns was that
On Wed, 2009-09-09 at 15:10 -0400, Robert Haas wrote:
> On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Another possible example is sprintf:
> >
> >> create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
> >> returns text
> >
> >> In order for thi
Hannu Krosing 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 typmod for function
Tom Lane wrote:
> Andrew Dunstan 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
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 :
> On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
>> 2009/9/9 Alvaro Herrera :
>> > Pavel Stehule escribió:
>> >> 2009/9/9 Alvaro Herrera :
>> >
>> >> > I already published a pseudo-sprintf function in the wiki here:
>> >> > http://wiki.postgresql.org/wiki/Sprintf
Tom Lane wrote:
Andrew Dunstan 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 th
Josh Berkus 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 I've had a n
On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
> 2009/9/9 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> 2009/9/9 Alvaro Herrera :
> >
> >> > I already published a pseudo-sprintf function in the wiki here:
> >> > http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
> >> >
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. Th
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 Wed, 2009-09-09 at 16:34 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Andrew Dunstan 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
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
"Dann Corbit" 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 any rows
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
http://doc.ddart.net/mssql/sql70/impt_bcp_16.h
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.
Functi
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 th
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)
S
Hi,
Tom Lane writes:
> Hannu Krosing 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 function argument/result types.
> I
David Fetter 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 bug. Nice tr
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 t
On Wed, Sep 09, 2009 at 06:35:05PM -0400, Tom Lane wrote:
> David Fetter 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 documented in
On Wed, Sep 9, 2009 at 4:13 PM, Tom Lane wrote:
> Andrew Dunstan 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
>> fil
David Fetter 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, which is pretty
e
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 c
On Wed, Sep 9, 2009 at 3:23 PM, 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, not Haskell.
On Wed, Sep 9, 2009 at 7:41 PM, Andrew Dunstan 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 doing
>> an
On Wed, Sep 9, 2009 at 6:24 PM, David Fetter 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 list (pgsql-hacke
1 - 100 of 116 matches
Mail list logo
