PGconn *PQconnectParams(const char **params)
Where "params" is an array with an even number of parameters, forming
key/value pairs. Usage example:
Maybe use the term properties (props for short) or options instead of params?
Params is already in heavy use. How about PQconnectProps(...) or
On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
> 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
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas wrote:
>
> Could we
> have a version of PQconnectdb() with an API more suited for setting the
> params programmatically? The PQsetdbLogin() approach doesn't scale as
> parameters are added/removed in future versions, but we could have
> something
On Wed, 2009-09-09 at 11:30 -0500, decibel wrote:
> On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote:
> > How is this better than just reading the information directly from
> > pg_depend?
>
> pg_depend is very difficult to use. You have to really, really know
> the catalogs to be able to figur
Robert Haas writes:
> On Wed, Sep 9, 2009 at 11:01 PM, Tom Lane wrote:
>> The thought that comes to mind for me is something "in front of" copy,
>> that is, give it the text of each line and let it do a text-to-text
>> transformation before COPY chews on it.
> That seems to me to be a whole lot l
On Wed, Sep 09, 2009 at 09:13:40PM -0400, Robert Haas wrote:
> Folks,
>
> CommitFest 2009-09 is now only days away! I have been having
> discussions with a number of people, and the result of those
> discussions is that I have agreed to manage the next CommitFest
> insofar as patch assignment is
Andrew Dunstan writes:
> you mean some sort of filter mechanism?
> COPY FILTER function_name ( args) ... ?
> That might work. Then we could provide a couple builtin and people could
> write others in C or PL/dujour.
Yeah, that's pretty much what I was thinking, although exactly where the
Tom Lane wrote:
What you're talking about is a
fairly specialized single-purpose feature, which nonetheless is going to
require a lot of infrastructure (for example, teaching psql's \copy
about it).
Well, that's hardly a lot.
Perhaps, for approximately the same amount of overhead,
we coul
> "Robert" == Robert Haas writes:
>> Just to pick up on some points from the discussion:
>>
>> 1. LATERAL has to be explicit because it changes the scope of
>> references. For example, in:
>> ... (select ... FROM (select a AS b), (select b)) ...
>> the "b" in the second subselect coul
On Wed, Sep 9, 2009 at 11:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> I wonder whether it would be appropriate to do something like
>>> implement a method by which copy could return text[] and then one
>>> could write wrappers around that functionality to do this as w
Robert Haas wrote:
However, I'm skeptical about whether the specific
thing you want to do after parsing (namely, drop excess columns,
null-fill missing ones) is sufficiently common to warrant a feature to
do only that. YMMV, of course.
So might my experience. I can tell you that I have
Andrew Dunstan writes:
> Robert Haas wrote:
>> I wonder whether it would be appropriate to do something like
>> implement a method by which copy could return text[] and then one
>> could write wrappers around that functionality to do this as well as
>> other things.
> Anything along these lines
On Wed, Sep 9, 2009 at 10:40 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>
>> I wonder whether it would be appropriate to do something like
>> implement a method by which copy could return text[] and then one
>> could write wrappers around that functionality to do this as well as
>> other thing
Robert Haas wrote:
I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that functionality to do this as well as
other things.
It's not a function ... writing a copy() function returnin
Folks,
CommitFest 2009-09 is now only days away! I have been having
discussions with a number of people, and the result of those
discussions is that I have agreed to manage the next CommitFest
insofar as patch assignment is concerned. Selena Deckelmann, Stephen
Frost, and Brendan Jurd have agree
On Wed, Sep 09, 2009 at 08:45:06PM -0400, Robert Haas wrote:
> 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
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
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 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.
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
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
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
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
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
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
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
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
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
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
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
"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
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, 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 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,
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, 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:
> 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
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
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
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
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
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
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
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 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
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 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 <
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
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
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 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
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
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
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 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
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
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
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
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
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
* 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
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
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 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
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 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
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
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 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
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
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
"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
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.
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
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
"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()
"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
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
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
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
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
"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
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
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
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: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
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 -
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
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
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
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,
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
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
"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:
> 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
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
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
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:
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
1 - 100 of 116 matches
Mail list logo
