http://www.atlassian.com/software/jira/pricing.jsp
I have no particular opinion on whether to use a free or non-free system
to track bugs, but I'd like to recommend RT as being a very capable and
useful program. It has been used to track Perl 5 and CPAN bugs for some
time now, and it happens to
At 2003-12-07 18:19:26 +0100, [EMAIL PROTECTED] wrote:
There is a new type in C99 for integer that can hold a pointer
value. I think it's called intptr_t resp. uintptr_t, but I don't have
the standard around.
Yes, they're called intptr_t and uintptr_t (§7.18.1.4), but they're both
optional
The documentation for PQexecPrepared says:
(There is not currently a provision to obtain different result
columns in different formats, although that is possible in the
underlying protocol.)
Would anyone be interested in a patch to allow this?
I could, for example, change
At 2004-06-18 13:11:19 -0400, [EMAIL PROTECTED] wrote:
Would anyone be interested in a patch to allow this?
Yes, but not the way you suggest. The ... approach forces calling
code to know *when it is written* how many result columns there will
be, because you'd have to actually write that
PostgreSQL currently uses $1/$2 for placeholders in prepared statements.
I'm writing something that may potentially submit queries to both Oracle
and Postgres, and it seems Oracle doesn't accept this syntax. Someone on
IRC said I could use ? for both Oracle and Postgres. It isn't entirely
clear to
At 2004-07-02 08:55:56 -0400, [EMAIL PROTECTED] wrote:
In the meantime, does this solve your problem?:
#ifndef eval_pv
#define eval_pv perl_eval_pv
#endif
The right way to do this is to #include ppport.h from Devel::PPPort.
-- ams
---(end of
At 2004-06-24 13:13:42 -0400, [EMAIL PROTECTED] wrote:
This is why I proposed originally to keep the non-transactional
behavior for Parse messages, but transactional for SQL PREPARE.
The latter can be said to be inside the transaction and should
behave like so. I think this lowers the
At 2004-07-03 08:20:17 +0530, [EMAIL PROTECTED] wrote:
I would not object to changing PREPARE to be transactional while
leaving Parse messages alone.
That is to say, it wouldn't cause any problems for me. But since it does
seem to be a nuisance for Oliver and Merlin (among others), I agree
At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote:
Assuming that anyone steps up and does the work, that is.
So...any volunteers?
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
That means you also need to add a new Execute method that takes a
portalName instead of a command.
Yes, thanks. How about these functions, then?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
I assumed we would want a separate Bind and execute call. Do we?
Yes, we do. (See below.)
Personally I find it annoying
At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote:
What you should be concerned with right now is providing an API for
Parse + Describe Statement, to substitute for the existing approach
of setting up statement objects via PQexec(PREPARE foo ...).
Fair enough. That's why my original
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
(1) What about preparing an unnamed statement ...
stmtName == will work.
(2) What about discovering the actually resolved parameter types?
I'm not sure what to do about that.
I could extend PGresult to hold ParameterDescription
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
Personally I find it annoying that you can't call describe on a
statement, only a portal, but that's the way it is now.
No, it isn't. Describe accepts both prepared statement and portal names.
In the former case, it returns
(I apologise for the delayed response.)
At 2004-10-07 01:23:56 -0400, [EMAIL PROTECTED] wrote:
So why is this part of the patch ok? Isn't it going to make libpq get
confused every time a PQExecPrepared sends a v3.0 prepare message?
I thought about that for a while, but I couldn't find
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow
At 2004-10-05 17:48:27 -0400, [EMAIL PROTECTED] wrote:
Searching for all references to one of the existing entry points such
as PQexecPrepared will probably help you identify what you need to do.
OK. I've attached two additional patches below.
I don't really understand how the *.def files
*/
/*
* Test program for PQprepare/PQdescribe.
* Abhijit Menon-Sen [EMAIL PROTECTED]
*
* create table pqtest (a int, b text, c text);
* insert into pqtest (a,b,c) values (1,'foo','bar');
* insert into pqtest (a,b,c) values (1,'foo','baz');
* insert into pqtest (a,b,c) values (2,'foo','barf
(Sorry for the delayed response. I just got home from Germany after my
visit to Linuxtag, and I'm catching up with my -hackers email now.)
At 2005-06-25 09:30:17 -0400, pgman@candle.pha.pa.us wrote:
Hi, i have found several #ifdef NOT_USED marked code...
We keep such blocks of code around in
At 2005-06-28 15:14:29 +0200, [EMAIL PROTECTED] wrote:
I recall that it had something to do with IPv6, but I'm not sure.
Under Linux, if you bind to AF_INET6/::0, a subsequent bind to AF_INET/0
will fail, but the IPv4 address is also bound by the first call, and the
program will accept IPv4
At 2005-07-15 17:17:01 +0200, [EMAIL PROTECTED] wrote:
I needed prepared queries in plperl, but there's none, so I baked
a patch that defines two extra perl functions, spi_prepare and
spi_exec_prepared
Oh. I've been working on the same functionality this week following a
conversation with
At 2005-09-27 15:20:05 +0530, [EMAIL PROTECTED] wrote:
Can anyone please tell/point me where I can get the postgresql system
layout (I've an interest to contribute).
http://www.postgresql.org/developer/coding
And, in particular:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html
-- ams
This weekend, I decided to teach Ethereal to decode the FE/BE protocol
properly: until now, it could only extract likely-looking strings from
the conversation, which I found woefully inadequate for debugging. I'm
hoping the result will be useful to other people too:
At 2004-12-19 17:56:00 +0530, [EMAIL PROTECTED] wrote:
I've asked the Ethereal people if they want to distribute this with
Ethereal.
It's in Ethereal CVS now.
-- ams
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
At 2004-12-31 23:49:35 -0500, pgman@candle.pha.pa.us wrote:
With 8.0 coming out in 2005, I think I should update the copyrights on
the files.
I don't think it actually makes any difference.
-- ams
---(end of broadcast)---
TIP 3: if
At 2005-02-01 11:02:52 +0100, [EMAIL PROTECTED] wrote:
We really should reimplement our query language in Scheme and
implement SQL on top of that. It will make many things much
easier. :-)
Speaking of which, see http://schematics.sourceforge.net
-- ams
---(end of
At 2005-02-01 16:31:32 +0530, [EMAIL PROTECTED] wrote:
Speaking of which, see http://schematics.sourceforge.net
Actually, http://schematics.sourceforge.net/schemeql.html
-- ams
---(end of broadcast)---
TIP 3: if posting/reading through Usenet,
At 2005-02-07 12:28:34 -0500, [EMAIL PROTECTED] wrote:
There was some mention of an upgrade tool which would avoid the need
for a dump/restore - did that idea die?
No, but I don't see anyone volunteering to work on it now
I like the idea of having a working pg_upgrade (independent of the
At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote:
Should our multi-byte encoding be referred to as UTF8 or Unicode?
The *encoding* should certainly be referred to as UTF-8. Unicode is a
character set, not an encoding; Unicode characters may be encoded with
UTF-8, among other things.
Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be
a valid query.
I'm trying to insert a unique entry into this table:
create table bodyparts (
id serial primary key,
bytes integer not null,
lines integer not null,
At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote:
Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be
a valid query.
A couple of things I forgot to mention:
1. I turned the logging all the way up and I've uploaded the messages
from the crashing backend to
At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote:
I couldn't reproduce this with SQL PREPARE/EXECUTE statements in psql,
so I conjectured that it may have something to do with the parameter
types being unspecified. I added a statement-describe message between
the parse and the bind,
At 2005-02-19 23:18:01 +0530, [EMAIL PROTECTED] wrote:
If I change my code (by means of an unspeakably vile hack, but never
mind that) to specify each parameter types in the parse message, the
server no longer crashes.
In fact, it works if I specify only the two integer types, and leave the
At 2005-03-14 16:25:22 -0500, [EMAIL PROTECTED] wrote:
The file descriptor returned by open is the lowest numbered unused
descriptor. [...]
What is meant by unused?
Perhaps you should actually look at the standard.
The open( ) function shall return a file descriptor for the named
[EMAIL PROTECTED] wrote:
As the copyright owner, The PostgreSQL Global Development Group, has
the right to license the documentation any way they see fit.
The PGDG has never asked for copyright assignments from contributors (as
I gather the PHP folks do), so the copyright to Postgres is
At 2005-04-07 12:14:19 +1000, [EMAIL PROTECTED] wrote:
% tail /usr/local/pgsql/postmaster.log
LOG: statement: prepare foo(int, int) as select $1 + $2;
LOG: statement: execute foo(5, 10);
LOG: statement: execute foo(15, 20);
If you send a v3 protocol execute message instead of an SQL
Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe?
-- ams
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Hi.
I've been working on making it possible for PL/Perl users to fetch large
result sets one row at a time (the current spi_exec_query interface just
returns a big hash).
The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
an spi_fetchrow that calls SPI_cursor_fetch. It
At 2005-06-12 14:54:47 +0530, [EMAIL PROTECTED] wrote:
The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
an spi_fetchrow that calls SPI_cursor_fetch. It works well enough, but I
don't know how to reproduce spi_exec_query's error handling (it runs the
SPI_execute in a
I'd like to add support for specifying constant parameters when creating
a functional index, e.g. create index foo on bar (substr(baz, 1, 32));
Is this a good idea?
If so, I'd like to ask for some suggestions before I proceed any further
towards implementing it.
The arguments to the index
At 2006-09-05 10:23:19 -0400, [EMAIL PROTECTED] wrote:
Something like it ought to go into core, but personally I'd opt for
taking the opportunity to redesign the API, which was a bit crufty to
begin with.
I'm happy to do the work right away (not that there's much) if someone
suggests a better
At 2006-09-05 16:35:49 -0400, [EMAIL PROTECTED] wrote:
The biggest part of the work needed is to write the documentation ---
but we'd have to do that for Abhijit's patch too, since the userlocks
docs presumably fall under GPL along with the code.
I'll write the documentation, either for the
At 2006-09-06 18:01:38 -0400, [EMAIL PROTECTED] wrote:
That is, we'd log a Parse or Bind operation if it individually
exceeded the duration threshold, and not otherwise.
Ok.
If we've got support for logging the statement text and the parameter
values at Execute time, isn't logging the
At 2006-09-07 00:16:38 -0400, [EMAIL PROTECTED] wrote:
- Where would the code live, if it were in core?
- Shall I hack up the API you suggested in your earlier message?
are we still moving forward with this? I would love to see this go in
for 8.2.
I don't know about its going into 8.2 or
At 2006-09-05 05:47:58 -, [EMAIL PROTECTED] wrote:
that difficulty no longer exists now that Abhijit has posted his
clean-room rewrite (look for otherlock in -patches). Perhaps he
would be prepared to turn that into a patch against the core...
Absolutely. Just tell me where it should live
At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
What are we testing to be NULL here?
Do we expect str to changed at line 1715
No. (Read the comment just above the function.)
The code is like this, starting from line 1703:
if (str == NULL flinfo-fn_strict)
return (Datum)
At 2008-09-02 15:10:23 +0300, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] sgml]$ make man
As Alvaro noted recently, you need to use make man D2MDIR=/some/path.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2008-09-06 14:58:25 -0400, [EMAIL PROTECTED] wrote:
I wrote:
... define
\ef with no argument as being the command that presents an empty
CREATE FUNCTION command template to fill in.
No complaints? I'll go make that happen.
No complaints, it sounds fine to me.
What about the
At 2008-09-06 19:59:55 -0400, [EMAIL PROTECTED] wrote:
So I'm thinking it would be better to invent a has_sequence_privilege
family of functions.
Perhaps.
I certainly wouldn't object to that approach. If there had been such a
function, I would have used it; and, since has_table_privilege
Seen on a lamp standard in south Delhi:
http://toroid.org/misc/ne.jpeg
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At 2008-09-22 12:54:34 -0500, [EMAIL PROTECTED] wrote:
can we tell there is consensus in create a new has_sequence_privilege()?
Abhijit will you make it? if not i can make a try...
Yes, I'll do it.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
(Many thanks to Dimitri for bringing this thread to my attention.)
At 2010-01-11 10:46:10 +0100, mag...@hagander.net wrote:
As for AOX, my understanding is that it is no longer maintained, so
I'd be worried about choosing such a solution for a complex problem.
I'll keep this short: Oryx, the
Regarding this item in the TODO:
SQL*Net listener that makes PostgreSQL appear as an Oracle database
to clients
I recently had (an unrelated) reason to look into the SQL*Net protocol
and discovered that no documentation for it is publicly available, and
reverse-engineering it is
(This is my review of the small patch Peter posted on 2009-08-29. See
http://archives.postgresql.org/message-id/1251495487.18151.12.ca...@vanquo.pezone.net
for the original message.)
At 2009-08-29 00:38:07 +0300, pete...@gmx.net wrote:
Found an easy solution; see attached patch.
Neat. The
At 2009-09-16 01:18:10 -0500, jcasa...@systemguards.com.ec wrote:
ok, maybe this is not the most brilliant observation but someone has
to say it... keep the same case in the word parameter ;)
Oops, thanks. Re²vised patch attached.
-- ams
diff --git a/src/backend/utils/misc/guc-file.l
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote:
How does this compare with PLSQL?
I don't remember anything of PL/SQL myself, but Pavel Stehule had this
to say in response to the original post:
This behave is in conflict with PL/SQL, what should do some problems.
I thing, so I
(This is my review of the latest version of Stef Walter's samehost/net
patch, posted on 2009-09-17. See
http://archives.postgresql.org/message-id/4ab28043.3050...@memberwebs.com
for the original message.)
The patch applies and builds cleanly, and the samehost/samenet keywords
in pg_hba.conf work
(This is a partial review of the grantonall-20090810v2.diff patch posted
by Petr Jelinek on 2009-08-10 (hi PJMODOS!). See
http://archives.postgresql.org/message-id/4a7f5853.5010...@pjmodos.net
for the original message.)
I have not yet been able to do a complete review of this patch, but I am
At 2009-09-20 20:20:11 +0530, a...@toroid.org wrote:
1. The patch did apply to HEAD and build cleanly, but there are now a
couple of minor (documentation) conflicts.
To be more clear, what I meant is that it did apply and build cleanly
when it was posted, but things have drifted enough now
At 2009-09-27 12:54:48 -0400, robertmh...@gmail.com wrote:
If this patch looks good now, can you mark it Ready for Committer in
the CommitFest app?
Done.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2009-09-12 13:17:50 -0400, and...@dunslane.net wrote:
I have just noticed, somewhat to my chagrin, that while in a plperl
function that returns an array type you can return a perl arrayref,
like this:
return [qw(a b c)];
if the function returns a setof an array type you cannot do
At 2009-09-30 11:16:57 -0500, stef-l...@memberwebs.com wrote:
I've now added tests for sys/ioctl.h and net/if.h even though these
headers seemed to be common to all the unixes investigated.
Thanks. I've marked this ready for committer now.
FWIW, there are checks for various bad netmasks. I
At 2009-09-30 22:08:12 -0400, t...@sss.pgh.pa.us wrote:
# local connections via TCP/IP:
hostall all samehost @authmethod@
I think that's an excellent idea.
On the other hand, I tend to be slightly against the idea of changing
the default listen_addresses from
At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote:
I cannot find anything that is obviously 'elsewhere' in the docs -
does that need fixing, or do my searching skills need improving?
I don't know, but…
*starts reading source code* :-)
Look at what fe-protocol3.c:build_startup_packet()
Hi.
I'm working on a patch where if you say \ef foo in psql, it'll start
$EDITOR with a CREATE OR REPLACE FUNCTION statement to recreate the
function. So you edit and save and quit, and if you made any changes,
psql will execute the statement.
The psql(/command.c) parts of this are quite simple.
At 2008-06-15 23:35:34 -0400, [EMAIL PROTECTED] wrote:
There's been a lot of talk (but no action) about refactoring pg_dump
into a library plus wrapper.
Yes. After having tried to do what would have amounted to just a small
part of that work, I can see why nobody has done it yet.
I'd much
At 2008-06-26 18:51:46 -0400, [EMAIL PROTECTED] wrote:
I propose we close the patches list and tell everyone to start using
only the hackers list.
That's an excellent idea.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2008-06-30 13:17:42 +0200, [EMAIL PROTECTED] wrote:
It seems that the most efficient way to communicate with the
DB would be through PQexecParams(), which avoids the whole
bytea-encoding issues.
Yes.
Does it become $10 or ${10} or $(10) or is it simply not possible
te reference more
At 2008-07-02 09:16:30 +0200, [EMAIL PROTECTED] wrote:
I don't think we should add support for pre-7.4 releases.
I agree. It's not worth the effort.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote:
# WITH RECURSIVE repository
% git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git
Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/
fatal: The remote end hung up unexpectedly
Run git-clone
These are my review comments on Mark Woodward's SSL configure patch:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
1. To begin
At 2008-07-08 08:27:29 +0530, [EMAIL PROTECTED] wrote:
(The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
apply cleanly to the latest source, but I'm ignoring both problems for
the moment.)
It wasn't hard to fix those, so I've attached an updated patch here.
Finally, I
At 2008-07-03 16:36:02 +0200, [EMAIL PROTECTED] wrote:
Here's a patch for this.
I reviewed the patch, it basically looks fine. A few quibbles with the
provided documentation:
+ Reports the number of pages which can be stored within a file
segment.
+ The total physical
At 2008-07-08 09:32:44 -0400, [EMAIL PROTECTED] wrote:
The idea of this patch is to avoid the need to make explicit
grants on sequences owned by tables. [...]
I had a look at this patch and it looks good. The only thing that's
not clear to me is whether we have agreed we want this to be
At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
No, actually I meant having a lone list = lappend(list, newseq); in
the loop, so that ExecGrantStmt_oids is called only once.
Yes, I understand what you meant. I just phrased my agreement poorly.
Here's a more precise phrasing. ;-)
(I
At 2008-07-09 17:06:19 -0700, [EMAIL PROTECTED] wrote:
I'm really new to this git thing, but I now have access to create
git-shell accounts, etc. on git.postgresql.org. Any ideas you can
offer on how better to handle this would really help me. :)
The question is: what is your objective in
(I don't really have much to add to the discussion here; I'm just
posting for the record on the question of client behaviour, since
I also wrote and maintain a client library in C++.)
At 2008-07-10 18:40:03 +0200, [EMAIL PROTECTED] wrote:
I start returning rows as they arrive, and pause reading
At 2008-07-10 07:18:28 -0700, [EMAIL PROTECTED] wrote:
Here are my objectives:
1. Make a repository that keeps up with CVS HEAD.
2. Allow people who are not currently committers on CVS HEAD to
make needed changes.
OK. Then, to begin with, I think it is very important to make the
Hi Zoltán.
I was reading through your posix_fadvise patch, and I wanted to ask
about this change in particular:
--- a/src/backend/executor/nodeIndexscan.c
+++ b/src/backend/executor/nodeIndexscan.c
@@ -290,7 +290,7 @@ ExecIndexEvalArrayKeys(ExprContext *econtext,
/* We want to keep
At 2008-07-11 19:10:16 +0900, [EMAIL PROTECTED] wrote:
And I have a question. Is it legal to use a pointer value as a
condition, like `while (!pointer) ...' ?
Yes, it's fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
At 2008-07-08 13:50:24 +0100, [EMAIL PROTECTED] wrote:
I can tell you from the perspective of CF coordinator, it's a PITA.
I felt so too at first, but I'm comfortable with it now.
Then I'm in awe of your wiki-editing skills. After keeping at it for a
few days, I've given up trying to do
At 2008-07-11 11:57:37 -0500, [EMAIL PROTECTED] wrote:
attached is a new version of the patch, it implements Alvaro's
suggestion and fix a bug i found (it wasn't managing GRANT ALL) :(
Looks good to me.
About the SELECT issue, AFAIU Robert doesn't complaint he just asked
what is the use
At 2008-07-12 00:52:42 +0100, [EMAIL PROTECTED] wrote:
There was some discussion about this change and in fact if you
look at CVS HEAD you'll find it already applied.
Not as far as I can see.
Incrementing the most significant index keys would maximize the
distance we're jumpin around in the
At 2008-07-12 14:32:03 -0500, [EMAIL PROTECTED] wrote:
Should be Granting permissions on a table automatically extends
those permissions to
what about extends them to...
Yes, sounds fine, thanks.
But I notice that nobody else has commented on whether they want this
feature or not.
Refactoring pg_dump was more work than I had time to do right now, and I
wanted \ef to work, so I hacked up the attached (by copying dumpFunc and
its dependencies to src/bin/psql/dumpfunc.[ch]).
-- ams
*** a/src/bin/psql/Makefile
--- b/src/bin/psql/Makefile
***
*** 21,27 override
At 2008-07-15 10:33:02 -0400, [EMAIL PROTECTED] wrote:
I doubt we'd consider accepting a patch done this way.
Yes, it's much too ugly to live. I was posting it only for the record,
I should have made that clear.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
At 2008-07-15 08:34:01 -0700, [EMAIL PROTECTED] wrote:
An answer of Jerry Stuckle:
Please stop cross-posting messages from this list to whatever MySQL list
you're on. It's a boring, pointless waste of time at best, and at worst
will get you written off as a troll in both places pretty soon.
--
At 2008-07-15 20:28:39 +0530, [EMAIL PROTECTED] wrote:
I doubt we'd consider accepting a patch done this way.
Yes, it's much too ugly to live.
Though I must say it would have been even MORE horrible to copy all this
code into the backend to make pg_get_functiondef(), notwithstanding the
At 2008-07-17 18:28:19 -0400, [EMAIL PROTECTED] wrote:
It wouldn't take a whole lot to convince me that a pg_get_functiondef
would be useful, although I don't foresee either of those applications
wanting to use it because of their backward-compatibility constraints.
If the code lives in psql
At 2008-07-23 10:50:03 -0400, [EMAIL PROTECTED] wrote:
What would the function return? CREATE OR REPLACE FUNCTION ...?
I think I'd go with CREATE FUNCTION for simplicity.
OK, I have a mostly working pg_get_functiondef now, and some questions
about the remaining pieces:
1. Why is prorows a
At 2008-07-29 15:42:27 +0530, [EMAIL PROTECTED] wrote:
OK, I have a mostly working pg_get_functiondef now, and some
questions about the remaining pieces:
While I look for answers to those questions, here's the patch as it
stands now, in case anyone feels like reading through it.
-- ams
diff
I have attached two patches:
- funcdef.diff implements pg_get_functiondef()
- edit.diff implements \ef function in psql based on (1).
Comments appreciated.
-- ams
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h
index 1ba20b0..ccf0d68 100644
---
I just noticed, to my dismay, that has_table_privilege() does not allow
me to check for usage privileges on sequences. I suspect this may have
been an oversight. If so, the attached patch fixes it for me.
-- ams
*** a/src/backend/utils/adt/acl.c
--- b/src/backend/utils/adt/acl.c
***
My client library sends Parse/Bind/Describe/Execute/Sync for each query,
unless it's using a previously-prepared statement, in which case it can
omit the Parse message.
For which statements can I also avoid sending Bind and Describe?
As far as I can tell, I can just send Parse/Execute/Sync for
At 2008-08-09 15:57:42 +0530, [EMAIL PROTECTED] wrote:
For which statements can I also avoid sending Bind and Describe?
I can't avoid sending Bind because Execute needs a portal and Bind is
what creates one. Let's pretend I didn't mention Bind at all. Sorry.
-- ams
--
Sent via pgsql-hackers
At 2008-08-28 20:09:21 +0900, [EMAIL PROTECTED] wrote:
For the git hosted projects, should we send in the latest patch file
to this list?
Yes, please do that.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
The server logs WARNING: nonstandard use of \\ in a string literal at
character 44, but the message comes with sqlstate code 22P06, which is
in an error class (Data exception). So my application thinks it's an
error, and is unhappy.
Since the sqlstate code is the only useful machine-readable
At 2010-05-25 07:35:34 -0400, alex-goncha...@comcast.net wrote:
| Where does the result set (GBs of data) reside after I call
| PQexecPrepared? On BE, I hope?
Unless you explicitly declare and fetch from an SQL-level cursor, your
many GBs of data are going to be transmitted to libpq, which
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote:
I don't see any advantage of FOR. We can change ir to support new
standard or don't change it.
Adopting FOR would mean we don't use AS in a way that conflicts with the
standard. That's its only advantage. But I agree with you, I
1 - 100 of 469 matches
Mail list logo
