David Fetter da...@fetter.org writes:
Tom,
I know you've been busy with lots of stuff, so here's a little
reminder. I talked with a couple of people who know the back-end much
better than I do. One said the above was way under-specified, and the
other said he'd started work on it, but
On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Tom,
I know you've been busy with lots of stuff, so here's a little
reminder. I talked with a couple of people who know the back-end
much better than I do. One said the above was way
On Mon, 2008-12-15 at 09:12 -0800, David Fetter wrote:
On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Tom,
Since you're the one who brought this up, I think it's on you to
flesh it out at least a little bit, or at least to describe it
David Fetter da...@fetter.org writes:
On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote:
I'm sorry, but I have far too much work in front of me reviewing
patches that have a chance of getting into 8.4. I do not have time
to do pre-implementation research for a patch that doesn't.
You
On Mon, Nov 17, 2008 at 10:37:41AM -0800, David Fetter wrote:
On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
On Thu, Oct 30, 2008 at 05:16, Tom Lane t...@sss.pgh.pa.us wrote:
which doesn't seem like it would amount to anything compared
On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
Surely they all have a way to call a SQL function that returns text.
Sure but when you call that function you get *that*
Alex Hunsaker [EMAIL PROTECTED] writes:
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
Surely they all have a way to call a SQL function that returns text.
Sure but when you call that function you get *that* functions
qualifier. And unless there already is a way to grab the
On Mon, Nov 03, 2008 at 10:02:24AM -0300, Alvaro Herrera wrote:
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This
Alvaro Herrera [EMAIL PROTECTED] writes:
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This little lacuna seems to say that if you
David Fetter wrote:
I understand that a full implementation of SQL/MED will involve just
about every part of PostgreSQL, but we've got a case of le mieux est
l'enemi du bien with this contrived example, which I included so
people could be fully informed when using this very helpful new
David Fetter [EMAIL PROTECTED] writes:
Left out are the very large benefits that, for example,
dblink gets for free.
I take it that works reliably isn't a property you think dblink
needs to have.
regards, tom lane
--
Sent via pgsql-hackers mailing list
I wrote:
... I'm not even real sure what
all the issues would be, but I'm pretty sure that subplans are just the
tip of the iceberg.
Another issue is that ruleutils responds to column aliasing, as indeed
it must to generate correct output for rules:
regression=# explain select * from tenk1 a
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This little lacuna seems to say that if you pass the wrong query to
dblink, it
On Fri, Oct 31, 2008 at 07:48, David Fetter [EMAIL PROTECTED] wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
I was assigned to
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
David Fetter [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
I would argue that it's already designed wrong if there's need for
PL-specific implementation effort.
I'm not sure how else to do
On Wed, Oct 29, 2008 at 09:40:00AM -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE FUNCTION show_qual()
RETURNS TEXT
LANGUAGE plperl
AS $$
return
On Fri, Oct 31, 2008 at 01:37:00PM -0400, Robert Haas wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU
I'll look at adding this to pl/pythonu.
I would argue
David Fetter [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
I would argue that it's already designed wrong if there's need for
PL-specific implementation effort.
I'm not sure how else to do this. The current implementation returns
char *, which doesn't
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as part of 8.4, as SQL/MED is just way too ambitious
given the
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote:
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU and PL/Tcl? To
the rest of the PLs? Would it make any sense to have it in SQL
language functions?
On Wed, 2008-10-29 at 10:33 -0700, Joshua D. Drake wrote:
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU
I'll look at adding this to pl/pythonu.
I would argue that it's already
David Blewett [EMAIL PROTECTED] writes:
Here's a vote for allowing this in plain SQL.
I use the tablefunc contrib module as a way to build a view of a
specific questionnaire's responses (using Elein's nice model here
[1]). Currently, if I then write queries against these views that
include
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote:
Also, PL/Perl shouldn't be the only language to have this
capability. How might we add similar capabilities to PL/PythonU
I'll look
29 matches
Mail list logo