Hello, Tom.
You wrote:
TL> Greg Smith writes:
>> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
>>> On MacOS X and Microsoft Windows, the world is far more messy. There
>>> are several ways to install libpq (one-click installer, fink,
>>> MacPorts, ...), and each of these ways allows the user
Hello
For join of encoded text should be useful fast concat aggregation. The
behave should be very similar to string_agg, only separator is useless
in this case.
a) This allow a fast only sql expressions on encoded texts
b) our interface will be more orthogonal
Regards
Pavel
--
Sent via pgsql
Hello
2011/12/12 Albe Laurenz :
> Pavel Stehule wrote:
>> there is merged patch
>
> Works fine, except that there are still missing const qualifiers
> in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
>
> One thing I forgot to mention:
> I thought there was a consensus to add a WITH(
On 14 December 2011 04:21, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 13, 2011 at 6:30 PM, Thomas Munro wrote:
>>> I imagine a very simple system like this, somehow built on top of
>>> the existing NOTIFY infrastructure:
>
>> I'm not sure whether we'd want something like this in core,
On 12/13/2011 08:11 PM, Joshua D. Drake wrote:
Because the use of Java/JDBC dwarfs both of your examples combined.
Don't get me wrong, I love Python (everyone knows this) but in terms
of where the work is being done it is still in Java for the most part,
by far.
I was talking about better tar
Robert Haas writes:
> On Tue, Dec 13, 2011 at 6:30 PM, Thomas Munro wrote:
>> I imagine a very simple system like this, somehow built on top of
>> the existing NOTIFY infrastructure:
> I'm not sure whether we'd want something like this in core, so for a
> first go-around, you might want to consi
If you add this Assert to lock.c:
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 3ba4671..d9c15e0 100644
*** a/src/backend/storage/lmgr/lock.c
--- b/src/backend/storage/lmgr/lock.c
*** GetRunningTransactionLocks(int *nlocks)
*** 3195,3200
---
On Tue, Dec 13, 2011 at 6:30 PM, Thomas Munro wrote:
> It seems there are number of academic and commercial
> systems (StreamSQL [1], CQL [2], ...) which provide powerful
> queryable streams of tuples, including windowing, grouping,
> joining and pipelining facilities, all of which are far beyond
On 12/13/2011 9:59 AM, Robert Haas wrote:
it. Dimitri says that he wants it so that we can add support for
CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and
Londiste. My fear is that it won't turn out to be adequate to that
task, because there won't actually be enough information
On 12/13/2011 04:54 PM, Greg Smith wrote:
On 12/13/2011 05:45 PM, Alexander Shulgin wrote:
Before that, why don't also accept "psql://", "pgsql://", "postgre://"
and anything else? Or wait, aren't we adding to the soup again (or
rather putting the soup right into libpq?)
There are multiple UR
On 12/13/2011 05:45 PM, Alexander Shulgin wrote:
Before that, why don't also accept "psql://", "pgsql://", "postgre://"
and anything else? Or wait, aren't we adding to the soup again (or
rather putting the soup right into libpq?)
There are multiple URI samples within PostgreSQL drivers in the
Hi,
I've used LISTEN/NOTIFY in a few apps with great success (both
the new and the old implementation) but I've found myself
wondering why I couldn't use a richer payload, and wondered if
anyone already had plans in this direction.
It seems there are number of academic and commercial
systems (Str
On 12/13/2011 03:22 PM, Peter Eisentraut wrote:
Well, the existing include directive works relative to the directory the
including file is in. If includedir works differently from that, that
would be highly confusing.
Right, and that's gone now; latest update matches the regular include
b
Excerpts from Robert Haas's message of Tue Dec 13 23:31:32 +0200 2011:
>
> On Mon, Dec 12, 2011 at 6:55 PM, Peter van Hardenberg wrote:
> > I'd like to make the controversial proposal that the URL prefix should
> > be "postgres:" instead of "postgresql:". Postgres is a widely accepted
> > nickna
* Greg Smith (g...@2ndquadrant.com) wrote:
> This answers Lionel's question, but I'm curious for a more user
> impact opinion from you. Given that pgAdmin III has given up on MIT
> KRB5, would you feel doing the same is appropriate for LibreOffice
> too? It sounds like they really shouldn't take
On 12/13/2011 01:28 PM, Noah Misch wrote:
!
! Another possibility for this same sort of organization is to create a
! configuration file directory and put this information into files there.
! Other programs such asApache use a
!conf.d directory for this purpose. And using num
Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> > +/*
> > + * If the tuple we're updating is locked, we need to preserve this in
> > the
> > + * new tuple's Xmax as well as in the old tuple. Prepare the new xmax
> > + * value for these uses.
> > + *
>
On Mon, Dec 12, 2011 at 6:55 PM, Peter van Hardenberg wrote:
> I'd like to make the controversial proposal that the URL prefix should
> be "postgres:" instead of "postgresql:". Postgres is a widely accepted
> nickname for the project, and is eminently more pronounceable. Once
> the url is establis
On 12/12/2011 02:59 PM, Tom Lane wrote:
Peter Eisentraut writes:
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
clean that up while we're doing this
On Dec 13, 2011, at 13:57, Greg Smith wrote:
> With this idea still being pretty new, and several of the people popping out
> opinions in this thread being local--Theo, Stephen, myself--we've decided to
> make our local Baltimore/Washington PUG meeting this month be an excuse to
> hash some of
On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut wrote:
> On tis, 2011-12-13 at 08:44 -0500, Robert Haas wrote:
>> Just because all our languages are Turing-complete doesn't mean they
>> are all equally well-suited to every task. Of course, that doesn't
>> mean we'd add a whole new language just
On Sat, Dec 10, 2011 at 6:14 PM, Greg Smith wrote:
> On 12/02/2011 06:48 AM, Alexander Korotkov wrote:
>
>> Rebased with head.
>>
>
> Could you comment a little more on what changed? There were a couple of
> areas Tom commented on:
>
> -General code fixes
>
Expensibe usage of "Max" macro is fix
Hi!
On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis wrote:
> Thank you. I have attached a patch that's mostly just cleanup to this
> one.
>
Thanks a lot for cleanup. Path with applied cleanup is attached.
> Comments:
>
> * You use the term "ordinal range" quite a lot, which I haven't heard
> befo
Robert Haas wrote:
> On Mon, Dec 12, 2011 at 4:08 PM, Simon Riggs wrote:
> > On Mon, Dec 12, 2011 at 8:54 PM, Robert Haas wrote:
> >> There are way too many places that assume that the typmod can
> >> just be discarded.
> >
> > If true, that probably ought to be documented cos it sounds fairly
>
On tis, 2011-12-13 at 08:44 -0500, Robert Haas wrote:
> Just because all our languages are Turing-complete doesn't mean they
> are all equally well-suited to every task. Of course, that doesn't
> mean we'd add a whole new language just to get a JSON parser, but I
> don't think that's really what P
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby wrote:
> I've often wondered about adding uint2/4/8... I suspect it's actually pretty
> uncommon for people to put negative numbers into int fields, since one of
> their biggest uses seems to be surrogate keys.
>
> I realize that this opens a can of wo
On Tue, Dec 13, 2011 at 2:33 PM, Peter Eisentraut wrote:
> On tis, 2011-12-13 at 09:11 -0500, Greg Smith wrote:
>> Personal story on this. When my book came out, I was trying to take
>> the #1 spot on Packt's bestseller list, even if it was just for a day.
>> Never made it higher than #2. The #1
On tis, 2011-12-13 at 09:11 -0500, Greg Smith wrote:
> Personal story on this. When my book came out, I was trying to take
> the #1 spot on Packt's bestseller list, even if it was just for a day.
> Never made it higher than #2. The #1 spot the whole time was "jQuery
> 1.4 Reference Guide", discu
On Sat, Nov 26, 2011 at 2:50 PM, Dimitri Fontaine
wrote:
>> + /* Done with the snapshot used for parameter I/O and parsing/planning
>> */
>> + if (snapshot_set)
>> + PopActiveSnapshot();
>
> This comment needs adjusting.
I thought about adjusting it, but I didn't see what it
On tis, 2011-12-13 at 00:06 -0800, Peter van Hardenberg wrote:
> On Mon, Dec 12, 2011 at 9:25 PM, Peter Eisentraut wrote:
> > On mån, 2011-12-12 at 16:51 -0800, Peter van Hardenberg wrote:
> > You don't need a new PL to do that. The existing PLs can also parse
> > JSON. So that's not nearly enou
On tis, 2011-11-15 at 23:53 -0500, Greg Smith wrote:
> -Called by specifying "includedir ". No changes to the
> shipped postgresql.conf yet.
> -Takes an input directory name
> -If it's not an absolute path, considers that relative to the -D option
> (if specified) or PGDATA, the same logic used
Excerpts from Robert Haas's message of mar dic 13 12:51:54 -0300 2011:
> If you want this patch to be considered for application, you should
> post an updated patch which includes the necessary doc changes and add
> a link to it here:
>
> https://commitfest.postgresql.org/action/commitfest_view/
On 11/24/2011 11:33 AM, Theo Schlossnagle wrote:
I see the next steps being:
1) agreeing that a problem exists (I know one does, but I suppose
consensus is req'd)
2) agreeing that "hooks" are the right approach, if not propose a
different approach. (fwiw, it's incredible common)
3) reworkin
On Mon, Dec 12, 2011 at 01:34:24PM -0500, Greg Smith wrote:
[various things I agree with]
> -Don't bother trying to free individual bits of memory now that it's all
> in the same context. Saves some lines of code, and I do not miss the
> asserts I am no longer triggering.
In the postmaster,
On Tue, Dec 13, 2011 at 12:48:01PM -0500, Tom Lane wrote:
> Greg Smith writes:
>> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
>>> On MacOS X and Microsoft Windows, the world is far more messy. There
>>> are several ways to install libpq (one-click installer, fink,
>>> MacPorts, ...), and ea
On 2011-12-12 20:53, Peter Eisentraut wrote:
On sön, 2011-12-11 at 21:21 +0200, Peter Eisentraut wrote:
* Cannot restrict access to array types. After revoking usage from the
element type, the error is perhaps a bit misleading. (smallint[] vs
smallint)
postgres=> create table a (a int2[]);
ERR
On Dec 12, 2011, at 7:42 PM, Alvaro Herrera wrote:
> I remember there was the idea of doing something like this for regexes
> -- have a specialized data type that saves the trouble of parsing it.
> I imagine this is pretty much the same.
>
> Nobody got around to doing anything about it though.
On 12/13/2011 09:59 AM, Robert Haas wrote:
Well, the problem is that just because something better comes along
doesn't mean we'll actually deprecate and remove the old
functionality.
The examples you gave fall into three groups, and I think it's useful to
demarcate how they're different. Plea
On Sat, Nov 26, 2011 at 5:49 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
>> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund wrote:
>> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
>> >> I'd just as soon keep the fields in a logical order.
On Dec 6, 2011, at 12:06 PM, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander wrote:
I've been considering similar things, as you can find in the archives,
>>
Greg Smith writes:
> On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
>> On MacOS X and Microsoft Windows, the world is far more messy. There
>> are several ways to install libpq (one-click installer, fink,
>> MacPorts, ...), and each of these ways allows the user to select an
>> install location
On Tue, Dec 13, 2011 at 12:29 PM, Christopher Browne wrote:
> But perhaps it's sufficient to implement what, of COMMAND TRIGGERS,
> can be done, and we'll see, as we proceed, whether or not it's enough.
>
> It's conceivable that a first implementation won't be enough to
> implement DDL triggers fo
Heikki Linnakangas writes:
> Attached is a patch with those changes. I also I removed a few of the
> syntax error regression tests, that seemed excessive, plus some general
> naming and comment fiddling. I'll apply this tomorrow, if it still looks
> good to me after sleeping on it.
The code lo
Excerpts from Alex Goncharov's message of mar dic 13 13:43:35 -0300 2011:
> I.e., can one tell me to bother or not with the complete patch, based
> on the general idea, which wouldn't change for the complete patch?
So let's see the patch. In context diff format please, and also include
in-tree
2011/12/13 Robert Haas :
> On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires wrote:
>> Right, it seems to happen when the destination tablespace is the same
>> as the database's tbs, because, in this case, relation's tbs is set to
>> InvalidOid :
>> src/backend/commands/tablecmds.c line 8342
>>
>
On Tue, Dec 13, 2011 at 9:59 AM, Robert Haas wrote:
> Now, all that having been said, I also agree that the perfect can be
> the enemy of the good, and we go there frequently. The question I'm
> asking is not whether the feature is perfect, but whether it's
> adequate for even the most basic thin
On 12/13/2011 09:18 AM, Stephen Frost wrote:
The gist of the limitation is this- if you need to support decent
encryption in a cross-realm environment on Windows XP-age systems, you
need MIT KRB5. If you're on Windows 7 or something else recent, the
built-in Windows stuff w/ AES works fine.
On 12/13/2011 11:07 AM, Lionel Elie Mamane wrote:
On MacOS X and Microsoft Windows, the world is far more messy. There
are several ways to install libpq (one-click installer, fink,
MacPorts, ...), and each of these ways allows the user to select an
install location (or a prefix thereof) freely.
Teodor Sigaev writes:
>> However, I now have another question: what is the point of the
>> allTheSame mechanism? It seems to add quite a great deal of complexity,
> I thought about two options: separate code path in core to support
> a-lot-of-the-same-values with minimal support in support func
On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires wrote:
> Right, it seems to happen when the destination tablespace is the same
> as the database's tbs, because, in this case, relation's tbs is set to
> InvalidOid :
> src/backend/commands/tablecmds.c line 8342
>
> + rd_rel->reltablespace =
2011/12/13 Jaime Casanova :
> On Mon, Dec 12, 2011 at 10:54 AM, Julien Tachoires wrote:
>> 2011/12/10 Jaime Casanova :
>>> On Mon, Nov 28, 2011 at 1:32 PM, Julien Tachoires wrote:
>>>
> 2) after CLUSTER the index of the toast table gets moved to the same
> tablespace as the main table
>>>
2011/12/13 Tom Lane :
> Pavel Stehule writes:
>> 2011/12/13 Albe Laurenz :
>>> Either that, or couldn't you pass an option List as data type "internal"?
>
>> this is question - internal is most simply solution, but then we
>> cannot to call check function directly
>
> Yeah, one of the proposals fo
On Tue, Dec 13, 2011 at 11:01 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar dic 13 12:51:54 -0300 2011:
>> If you want this patch to be considered for application, you should
>> post an updated patch which includes the necessary doc changes and add
>> a link to it here:
>>
,--- I/Alex (Tue, 13 Dec 2011 07:55:45 -0500) *
| If the above change causes a warning in a client code, so much the
| better: the client code is doing something unreasonable like the "*s"
| assignment in my example above.
,--- Robert Haas (Tue, 13 Dec 2011 10:51:54 -0500) *
| Or they just
I wrote:
... the leaf tuple datatype is hard-wired to be
After another day's worth of hacking, I now understand the reason for
the above: when an index is less than a page and an incoming value would
still fit on the root page, the incoming value is simply dumped into a
leaf tuple without ever c
On 12.12.2011 21:55, Kevin Grittner wrote:
Yeb Havinga wrote:
Forgot to copy regression output to expected - attached v7 fixes
that.
This version addresses all of my concerns. It applies cleanly and
compiles without warning against current HEAD and performs as
advertised. I'm marking it Re
On Tue, Dec 13, 2011 at 01:09:46PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Noah Misch's message of mar dic 13 11:44:49 -0300 2011:
> >
> > On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> > > Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> > >
> >
Excerpts from Noah Misch's message of mar dic 13 11:44:49 -0300 2011:
>
> On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> > Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> >
> > > Second, I tried a SELECT FOR SHARE on a table of 1M tuples; this might
>
On Tue, Dec 13, 2011 at 10:43:26AM -0500, Tom Lane wrote:
> Lionel Elie Mamane writes:
>> LibreOffice can be configured at build-time to use Mozilla LDAP or
>> OpenLDAP. We patched postgresql's configure.in to build libpq with
>> Mozilla LDAP when requested to do so.
> Um, if I interpret this co
On Tue, Dec 13, 2011 at 8:59 AM, Robert Haas wrote:
> Now, all that having been said, I also agree that the perfect can be
> the enemy of the good, and we go there frequently. The question I'm
> asking is not whether the feature is perfect, but whether it's
> adequate for even the most basic thin
On Tue, Dec 13, 2011 at 10:53 AM, Merlin Moncure wrote:
> On Tue, Dec 13, 2011 at 8:59 AM, Robert Haas wrote:
>> Now, all that having been said, I also agree that the perfect can be
>> the enemy of the good, and we go there frequently. The question I'm
>> asking is not whether the feature is per
On Tue, Dec 13, 2011 at 7:55 AM, Alex Goncharov
wrote:
> If the above change causes a warning in a client code, so much the
> better: the client code is doing something unreasonable like the "*s"
> assignment in my example above.
Or they just haven't bothered to decorate their entire code-base wi
Lionel Elie Mamane writes:
> I've revived the old moribund / bitrotten OpenOffice driver for
> PostgreSQL (originally at
> http://dba.openoffice.org/drivers/postgresql/index.html). As you may
> already know, OpenOffice was forked into LibreOffice. Barring any
> unforeseen disaster, LibreOffice 3.5
On Dec 13, 2011, at 9:15 AM, Kevin Grittner wrote:
> Merlin Moncure wrote:
>
>> Postgres would in fact make a wonderful 'nosql' backend with some
>> fancy json support -- document style transmission to/from the
>> backend without sacrificing relational integrity in storage.
>> Properly done this
Pavel Stehule writes:
> 2011/12/13 Albe Laurenz :
>> Either that, or couldn't you pass an option List as data type "internal"?
> this is question - internal is most simply solution, but then we
> cannot to call check function directly
Yeah, one of the proposals for allowing people to specify com
Hi Greg
2011/12/13 Greg Smith :
> On 12/11/2011 05:29 PM, Torello Querci wrote:
>>
>> I will try to adjust the patch and submit for the next Commit Fest if
>> this is ok for you.
>>
>
>
> I don't think we'll need this, it will take a bit to explain why though.
>
> First, thanks for returning this
On Tue, Dec 13, 2011 at 8:44 AM, Robert Haas wrote:
> Rather, I think the
> point is that embedded Javascript is *extremely* popular, lots and
> lots of people are supporting it, and we ought to seriously consider
> doing the same. It's hard to think of another PL that we could add
> that would g
Merlin Moncure wrote:
> Postgres would in fact make a wonderful 'nosql' backend with some
> fancy json support -- document style transmission to/from the
> backend without sacrificing relational integrity in storage.
> Properly done this would be a fabulous public relations coup
> (PostgreSQL =
On Tue, Dec 13, 2011 at 8:25 AM, Greg Smith wrote:
> There's another cautionary tale from the sepgsql history worth mentioning
> here, which surely I don't have to remind you about. Making the goal for a
> first shippable subset include proof you can solve the hardest problems in
> that area can
On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
>
> > Second, I tried a SELECT FOR SHARE on a table of 1M tuples; this might incur
> > some cost due to the now-guaranteed use of pg_multixact for FOR SHARE. See
On 12/13/2011 09:11 AM, Greg Smith wrote:
On 12/13/2011 08:44 AM, Robert Haas wrote:
Rather, I think the point is that embedded Javascript is *extremely*
popular, lots and
lots of people are supporting it, and we ought to seriously consider
doing the same. It's hard to think of another PL th
On Tue, Dec 13, 2011 at 8:11 AM, Greg Smith wrote:
> On 12/13/2011 08:44 AM, Robert Haas wrote:
>>
>> Rather, I think the point is that embedded Javascript is *extremely*
>> popular, lots and
>> lots of people are supporting it, and we ought to seriously consider
>> doing the same. It's hard to t
* Lionel Elie Mamane (lio...@mamane.lu) wrote:
> The "gsslib" parameter in the connection string won't work, but will
> that keep users from authenticating to some Kerberos domains, and/or
> are there other (interoperability?) issues that make it strongly
> desirable to link libpq with *both* SSPI
On 12/13/2011 08:44 AM, Robert Haas wrote:
Rather, I think the point is that embedded Javascript is *extremely*
popular, lots and
lots of people are supporting it, and we ought to seriously consider
doing the same. It's hard to think of another PL that we could add
that would give us anywhere n
2011/12/13 Robert Haas :
> On Tue, Dec 13, 2011 at 12:25 AM, Peter Eisentraut wrote:
>> On mån, 2011-12-12 at 16:51 -0800, Peter van Hardenberg wrote:
>>> Because we haven't heard from him in a while we've been using PL/V8 to
>>> validate a JSON datatype simulated by a DOMAIN with a simple
>>> acc
On Tue, Dec 13, 2011 at 12:25 AM, Peter Eisentraut wrote:
> On mån, 2011-12-12 at 16:51 -0800, Peter van Hardenberg wrote:
>> Because we haven't heard from him in a while we've been using PL/V8 to
>> validate a JSON datatype simulated by a DOMAIN with a simple
>> acceptance function. (See below.)
On 12/13/2011 03:15 AM, Joey Adams wrote:
We should probably have a wiki page titled "JSON datatype status" to
help break the cycle we're in
I was about to point you to
http://wiki.postgresql.org/wiki/JSON_API_Brainstorm , only to realize
you created that thing in the first place. There'
On 12/12/2011 11:32 AM, Robert Haas wrote:
I haven't yet thought about your specific proposal here in enough to
have a fully-formed opinion, but I am a little nervous that this may
turn out to be one of those cases where the obvious API ends up
working less well than might have been supposed.
T
2011/12/13 Albe Laurenz :
> Pavel Stehule wrote:
>>> One thing I forgot to mention:
>>> I thought there was a consensus to add a WITH() or OPTIONS() clause
>>> to pass options to the checker function:
>>> http://archives.postgresql.org/message-id/12568.1322669...@sss.pgh.pa.us
>>>
>>> I think this
Compare:
int PQntuples(const PGresult *res)
Reasonable: doesn't modify 'res'.
With:
char *PQcmdStatus(PGresult *res);
char *PQcmdTuples(PGresult *res);
Unreasonable:
a. What, these two can modify 'res' I pass in?..
b. Oh, yes, because they return 'char *' pointing to
'res->cmd
(2011/12/13 18:57), Albe Laurenz wrote:
> Maybe I'm missing something, but if pushdown worked as follows:
>
> - Push down only system functions and operators on system types.
> - Only push down what is guaranteed to work.
Oh, I didn't care whether system data types. Indeed user defined types
wou
(2011/12/13 20:04), Heikki Linnakangas wrote:
> The SQL/MED spec handles this with the concept of "routine mappings".
> There is syntax for defining which remote "routines", meaning functions,
> correspond local functions:
>
> CREATE ROUTINE MAPPING FOR designator>
> SERVER [ ]
>
> is FDW-
(See part 1 for general introduction)
LibreOffice currently - when it rebuilds libpq, such as for most of
our official binaries - links statically against libpq.
I noticed that pg_config does not give the information of what
additional libraries to include in the link to resolve all symbols
that
On 13.12.2011 11:57, Albe Laurenz wrote:
Tom Lane wrote:
Shigeru Hanada writes:
(2011/12/12 22:59), Robert Haas wrote:
... I feel like we might need a system here that
allows for more explicit user control about what to push down vs.
not,
rather than assuming we'll be able to figure it out
The submission from Edward Muller I'm replying to is quite similar to
what the other raging discussion here decided was the right level to
target. There was one last year from Josh Kupershmidt with similar
goals: http://archives.postgresql.org/pgsql-admin/2010-02/msg00052.php
A good place to
(See part 1 for general introduction)
LibreOffice currently - when it rebuilds libpq, such as for our
official MS Windows binaries - links libpq against only the MS
Windows built-in SSPI stuff, which if I understand well is an "embrace
and extend" Kerberos 5 implementation.
I wanted to understan
Hi,
I've revived the old moribund / bitrotten OpenOffice driver for
PostgreSQL (originally at
http://dba.openoffice.org/drivers/postgresql/index.html). As you may
already know, OpenOffice was forked into LibreOffice. Barring any
unforeseen disaster, LibreOffice 3.5 (to be released in early Februar
Pavel Stehule wrote:
>> One thing I forgot to mention:
>> I thought there was a consensus to add a WITH() or OPTIONS() clause
>> to pass options to the checker function:
>> http://archives.postgresql.org/message-id/12568.1322669...@sss.pgh.pa.us
>>
>> I think this should be there so that the API do
Tom Lane wrote:
> Shigeru Hanada writes:
>> (2011/12/12 22:59), Robert Haas wrote:
>>> ... I feel like we might need a system here that
>>> allows for more explicit user control about what to push down vs.
not,
>>> rather than assuming we'll be able to figure it out behind the
scenes.
>> Agreed.
On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian wrote:
> Where are we with adding JSON for Postgres 9.2? We got bogged down in
> the data representation last time we discussed this.
We should probably have a wiki page titled "JSON datatype status" to
help break the cycle we're in:
* Someone asks
On Mon, Dec 12, 2011 at 9:25 PM, Peter Eisentraut wrote:
> On mån, 2011-12-12 at 16:51 -0800, Peter van Hardenberg wrote:
> You don't need a new PL to do that. The existing PLs can also parse
> JSON. So that's not nearly enough of a reason to consider adding this
> new PL.
PL/V8 is interesting
On Mon, Dec 12, 2011 at 5:05 PM, David E. Wheeler wrote:
> On Dec 12, 2011, at 3:55 PM, Peter van Hardenberg wrote:
>> only a nearly insurmountable mailing list thread
>> prevents it.
>
> What happened to SexQL?
>
Case in point.
--
Peter van Hardenberg
San Francisco, California
"Everything was
92 matches
Mail list logo
