At 2013-07-13 14:19:23 +0530, a...@2ndquadrant.com wrote:
>
> The timings above are with both xid_in_snapshot_cache.v1.patch and
> cache_TransactionIdInProgress.v2.patch applied
For anyone who wants to try to reproduce the results, here's the patch I
used, which is both patches above plus some typ
At 2013-07-12 16:25:14 -0700, jeff.ja...@gmail.com wrote:
>
> I think the reviewer of a performance patch should do some independent
> testing of the performance, to replicate the author's numbers; and
> hopefully with a few different scenarios.
You're quite right. I apologise for being lazy; doub
At 2013-07-08 12:16:34 +0300, hlinnakan...@vmware.com wrote:
>
> Ok, I've committed this patch now. Finally, phew!
Good.
I'd signed up to review this patch, and did spend some considerable time
on it, but although I managed to understand what was going on (which was
my objective), I didn't find a
At 2013-07-11 17:47:58 -0700, j...@agliodbs.com wrote:
>
> So, where are we with this patch, then?
It's ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At 2013-07-10 09:47:34 -0700, j...@agliodbs.com wrote:
>
> Due to the apparent lack of performance testing, I'm setting this back
> to "needs review".
The original submission (i.e. the message linked from the CF page)
includes test results that showed a clear performance improvement.
Here's an exc
At 2013-06-24 10:16:33 +, laurenz.a...@wien.gv.at wrote:
>
> What do you think of the attached version?
I'm not exactly fond of it, but I can't come up with a better version
either. It's slightly better if "but may not accurately represent the
stored value" is removed.
Does anyone else have s
At 2013-03-06 10:04:25 +, laurenz.a...@wien.gv.at wrote:
>
> How about this elaboration?
Sorry to nitpick, but I don't like that either, on the grounds that if I
had been in Tom Duffey's place, this addition to the docs wouldn't help
me to understand and resolve the problem.
I'm not entirely
(Cc: to pgsql-performance dropped, pgsql-hackers added.)
At 2013-05-06 09:14:01 +0100, si...@2ndquadrant.com wrote:
>
> New version of patch attached which fixes a few bugs.
I read the patch, but only skimmed the earlier discussion about it. In
isolation, I can say that the patch applies cleanly
At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
>
> ALTER TABLE foo
>ALTER CONSTRAINT fktable_fk_fkey DEFERRED INITIALLY IMMEDIATE;
I read the patch (looks good), applied it on HEAD (fine), ran make check
(fine), and played with it in a test database. It looks great, and from
previo
At 2013-01-17 08:41:37 +, si...@2ndquadrant.com wrote:
>
> Jeff, can you summarise/collate why we're doing this, what concerns it
> raises and how you've dealt with them?
Since I was just looking at the original patch and discussion, and since
Pavan has posted an excerpt from one objection to
At 2013-01-17 16:05:05 +0900, michael.paqu...@gmail.com wrote:
>
> Is it really necessary to create a new commit fest just to move the
> items? Marking the patches that are considered as being too late for
> 9.3 should be just returned with feedback.
Opening 2013-03 is not so much to move existing
At 2013-01-16 22:40:07 -0500, t...@sss.pgh.pa.us wrote:
>
> However, since we already missed the scheduling agreed to then, the
> question that's on the table now is what we should do instead.
I suggest we close CF3 and bring the pending CF3 patches into CF4, but
still have a triage of CF4 patches
At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote:
>
> Regarding the actual comment, here's the wording that I'd use:
Sorry for nitpicking, but "we can't long jumps" made me cringe.
Here's a slightly more condensed version:
/*
* We can't use ereport(ERROR) here, because any longjmps
At 2013-01-16 09:02:45 -0500, sfr...@snowman.net wrote:
>
> So when can he start? :D
Also, what should he start with? CF3 as it stands today, or CF4 with all
of the pending patches moved from CF3, immense though the result may be?
I slightly prefer the latter, so that we're all on the same page wh
hat worked out - did we get that spread, or did we end up with the
> same ratio as last time?
Here's a breakdown based purely on the names from the CF page (i.e. I
didn't check archives to see who actually posted reviews, and didn't
take into account reviews posted without updating
At 2013-01-16 02:07:29 -0500, t...@sss.pgh.pa.us wrote:
>
> In case you hadn't noticed, we've totally lost control of
> the CF process.
What can we do to get it back on track?
I know various people (myself included) have been trying to keep CF3
moving, e.g. sending followup mail, adjusting patch
Hi.
This patch was marked "Needs review" with no reviewers in the ongoing
CF, so I decided to take a look at it. I see that Zoltan has posted a
review, so I've added him to the list.
But I took a look at the latest patch in any case. Here are some
comments, mostly cosmetic ones.
> diff -dcrpN po
At 2013-01-15 02:38:45 +0100, and...@2ndquadrant.com wrote:
>
> 2) Currently the logical replication infrastructure assigns a
> 'slot-id' when a new replica is setup. That slot id isn't really
> nice (e.g. "id-321578-3"). It also requires that [18] keeps state
> in a global variable to make writing
At 2013-01-14 18:15:39 -0800, j...@agliodbs.com wrote:
>
> Is there a git fork for logical replication somewhere?
git://git.postgresql.org/git/users/andresfreund/postgres.git, branch
xlog-decoding-rebasing-cf4 (and xlogreader_v4).
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hacker
At 2012-11-15 12:08:12 -0500, robertmh...@gmail.com wrote:
>
> Still, maybe we could have a src/framework directory that uses the
> same trick to produce a libpgframework that frontend code can use,
> and a lib pgframework_srv that can be linked into the backend.
> That's might not actually be that
At 2012-11-13 23:32:15 -0500, pete...@gmx.net wrote:
>
> I noticed we don't implement the recursive view syntax, even though
> it's part of the standard SQL feature set for recursive queries.
> Here is a patch to add that. It basically converts
>
> CREATE RECURSIVE VIEW name (columns) AS SELECT .
At 2012-11-21 15:09:12 -0500, robertmh...@gmail.com wrote:
>
> > The following comments still talk about "key and value", thus need
> > an update:
>
> Oops.
In the same vein, "Returns NULL if the heap is empty" no longer applies
to binaryheap_first and binaryheap_remove_first. Plus there is an ex
At 2012-11-20 22:55:52 -0500, t...@sss.pgh.pa.us wrote:
>
> BTW, I probably missed some context upthread, but why do we have two
> fields at all?
I would also have preferred to handle the nodeMergeAppend case using a
context pointer as you suggest, but Andres needs to store two pointers
in his hea
Hi.
A brief response to earlier messages in this thread:
1. I agree that it's a good idea to use Datum rather than void *.
2. I don't think it's worth getting rid of binaryheap_node.
3. I agree that it makes sense to go with what we have now (after
Robert's reworking of my patch) and reconside
At 2012-11-15 10:11:58 -0500, robertmh...@gmail.com wrote:
>
> It could use a run through pgindent.
Done.
> I think you want Assert(heap->size < heap->space).
Of course. Thanks for catching that.
> Project style is to omit braces for a single-line body.
I've removed most of them. In the few ca
Hi.
There are two or three places in the Postgres source that implement heap
sort (e.g. tuplesort.c, nodeMergeAppend.c), and it's also needed by the
BDR code. It seemed reasonable to factor out the functionality.
I've attached a patch (binaryheap.diff) that contains a straightforward
implementati
At 2012-10-21 14:27:39 -0400, t...@sss.pgh.pa.us wrote:
>
> Is that fundamentally an illegitimate optimization, and if so why?
I wouldn't say it's illegitimate. It's a bit less convenient for the
application programmer, and will surprise some people (even some who
know better than to expect SELECT
At 2012-10-21 11:49:26 -0400, cbbro...@gmail.com wrote:
>
> If there is a natural sequence (e.g. - a value assigned by nextval()),
> that offers a natural place to apply the usual order-imposing ORDER BY
> that we are expected to use elsewhere.
Note: "INSERT … RETURNING" doesn't accept an ORDER BY
At 2012-10-17 09:56:22 -0400, t...@sss.pgh.pa.us wrote:
>
> > Clarify that in the documentation, and also write a test case
> > that will prevent us from breaking the rule in the future.
>
> I don't believe this is a good idea in the slightest. Yeah, the
> current implementation happens to act li
At 2012-10-19 17:15:27 -0700, w...@heroku.com wrote:
>
> will=# \watch select now();
> Watch every 2s Fri Oct 19 17:09:23 2012
>
> now
> ---
> 2012-10-19 17:09:23.743176-07
> (1 row)
The patch looks OK at first glance, and I can confirm that it works as
At 2012-10-15 10:28:17 -0400, robertmh...@gmail.com wrote:
>
> > Is there any concise description that applies? […]
>
> I don't think there is. I think we need to replace those counters
> with something better. The status quo is quite bizarre.
Fair enough. Do you have any ideas?
I see two poss
At 2012-09-25 01:46:18 +0200, and...@2ndquadrant.com wrote:
>
> The attached patch fixes this issue. Haven't looked at the other one
> in detail yet.
Here are tests for both bugs. They currently fail with HEAD.
Note that the first test now uses PREPARE instead of the SELECTs in the
original examp
At 2012-10-17 09:19:58 -0400, and...@dunslane.net wrote:
>
> This doesn't appear to correct any ambiguity, nor any grammatical
> error.
FWIW, it's quite standard and uncontroversial "good writing" advice to
push "only" as far right as it can go. It does correct an ambiguity,
but in this case the a
At 2012-10-12 13:05:44 -0400, t...@sss.pgh.pa.us wrote:
>
> t_tuples_returned for instance is incremented by both
> pgstat_count_heap_getnext() (ie, successful returns from
> heap_getnext()) and pgstat_count_index_tuples() (which
> counts heap TIDs returned from either index_getnext_tid
> or index_
I'm making some changes to a program that, among other things, reports
tup_fetched/tup_returned as if it were a cache hit rate, analogous to
blks_hit/blks_fetched.
The documentation didn't help me to understand if that was appropriate,
so I looked at the source and asked on IRC. It seems I'm not t
At 2012-02-07 13:20:43 +0200, pete...@gmx.net wrote:
>
> Should we rename the options and/or add that to the documentation, or is
> the new behavior obvious and any new terminology would be too confusing?
I agree there is potential for confusion either way. I tried to come up
with a complete and n
At 2012-02-02 08:54:32 -0500, robertmh...@gmail.com wrote:
>
> Someone is eventually going to propose a function with a name like
> json_to_string() which, when given this JSON object, returns a
> three-character string with the PostgreSQL text type.
Ah, that's the bit I was missing. I thought y
At 2012-02-01 11:28:50 -0500, robertmh...@gmail.com wrote:
>
> It's also pretty clear that JSON
> string -> PG text data type is going to admit of a number of error
> conditions (transcoding errors and perhaps invalid surrogate pairs) so
> throwing one more on the pile doesn't cost much.
Hi Robert
At 2012-02-01 18:48:28 -0500, andrew.duns...@pgexperts.com wrote:
>
> For now I'm inclined not to proceed with that, and leave it as an
> optimization to be considered later if necessary. Thoughts?
I agree, there doesn't seem to be a pressing need to do it now.
-- ams
--
Sent via pgsql-hackers
At 2012-01-31 12:04:31 -0500, robertmh...@gmail.com wrote:
>
> That fails to answer the question of what we ought to do if we get an
> invalid sequence there.
I think it's best to categorically reject invalid surrogates as early as
possible, considering the number of bugs that are related to them
At 2012-01-27 09:47:05 +0530, a...@toroid.org wrote:
>
> I've started reviewing this patch, but it'll take me a bit longer to go
> through json.c properly.
OK, I finished reading json.c. I don't have an answer to the detoasting
question in the XXX comment, but the code looks fine.
Aside: is query
At 2012-01-15 11:08:05 -0500, and...@dunslane.net wrote:
>
> Here's an update that adds row_to_json, plus a bit more cleanup.
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly. Here are a few preliminary notes:
1. The patch has a lot of whitespace err
At 2012-01-17 13:43:11 -0800, dan...@heroku.com wrote:
>
> > See the attached patch. It has a detailed cover letter/comment at
> > the top of the file.
The patch looks good, but the resetxlog and controldata Makefile hunks
didn't apply. I don't know why, but I've attached updated versions of
thos
At 2012-01-09 20:23:59 +0200, pete...@gmx.net wrote:
>
> Nobody had a better idea, so here is the final patch. I adjusted the
> regression tests a bit to avoid bloat from the now-visible owner
> privileges.
Patch applies, builds, and passes tests (and does report EXECUTE
privileges on a newly-cre
At 2011-12-21 18:24:17 +0200, ma...@juffo.org wrote:
>
> > I think the least invasive fix, as proposed by Jeroen, is to fail only
> > when ERANGE is set *and* the return value is 0.0 or +/-HUGE_VAL.
> > Reading relevant specifications, this seems to be a fairly safe
> > assumption. That's what the
At 2012-01-11 22:05:34 +0200, pete...@gmx.net wrote:
>
> I propose to add two functions to the result object:
>
> .colnames() returns a list of column names (strings)
> .coltypes() returns a list of type OIDs (integers) […]
>
> Patch attached. Comments welcome.
Applies, builds, passes tests. Co
At 2011-11-24 17:44:16 +0100, pavel.steh...@gmail.com wrote:
>
> patch is relative long, but almost all are changes in regress tests.
> Changes in plpgsql are 5 lines
The change looks good in principle. The patch applies to HEAD with a bit
of fuzz and builds fine… but it fails tests, because it's
At 2012-01-12 12:31:20 +, si...@2ndquadrant.com wrote:
>
> The following patch adds a pgbench option -I to load data using
> INSERTs
This is just to confirm that the patch applies and builds and works
fine (though of course it does take a long time… pity there doesn't
seem to be any easy way t
At 2012-01-14 14:23:49 +0200, pete...@gmx.net wrote:
>
> Inspired by this question http://stackoverflow.com/questions/6857265 I
> have implemented a way to set the psql record and field separators to
> a zero byte (ASCII NUL character).
Since this patch is in the commitfest, I had a look at it.
I
At 2010-09-23 17:37:51 -0400, t...@sss.pgh.pa.us wrote:
>
> Hm. What git version are you using?
I'm using 1.7.3, yes. It has a bunch of timezone handling changes, but
I'm not sure if there's anything related to your problem. If you don't
have TZ set in your environment, I suppose the following pa
At 2010-09-23 15:52:24 -0400, t...@sss.pgh.pa.us wrote:
>
> Apparently somebody's confused between local and GMT time somewhere in
> there.
>
> This is with a vanilla build of 1.7.2.3. Anybody else see this type
> of symptom?
Not me. I just tried various combinations of commit in one branch and
c
At 2010-09-22 22:19:45 -0400, t...@sss.pgh.pa.us wrote:
>
> I can demonstrate that this is not so. Try a "git add" on such a file.
Works fine for me with v1.7.3 (no warnings, no need for add -f). What
version do you use?
If I try to add an untracked file which is already ignored, then I get
the
At 2010-09-22 20:54:19 -0400, t...@sss.pgh.pa.us wrote:
>
> However, it seems that git isn't so willing to tell you about gitignore
> patterns that cover too much, i.e. match files that are already in the
> repository.
If .gitignore specifies a pattern that matches something that's already
in the
At 2010-09-22 19:21:45 +0300, pete...@gmx.net wrote:
>
> Well, let's see. If someone can figure out the git equivalent of
>
> if cvs -q update | egrep -q '^(U|P) '; then
> # ... something changed, so run the update ...
> fi
I think you want:
git pull
if [ $(git rev-parse HEAD) != $(gi
At 2010-09-21 21:20:06 -0400, t...@sss.pgh.pa.us wrote:
>
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches.
I'd suggest using "git cherry-pick -x" (or something similar) to mark
backported patches:
-x When recording the c
At 2010-09-21 17:53:22 -0400, t...@sss.pgh.pa.us wrote:
>
> > Does anyone know offhand why the sizes are so different?
>
> Magnus did
> git gc --aggressive --prune
> during the conversion. I imagine it's the --aggressive that does it.
That's not it. I ran the same git gc command on my old
Hi.
My new clone of git://git.postgresql.org/git/postgresql.git is 196MB,
whereas my old clone (last synced around the beginning of September)
was 285MB.
Does anyone know offhand why the sizes are so different?
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
At 2010-09-21 12:45:20 -0400, t...@sss.pgh.pa.us wrote:
>
> Having done that, I now realize that the historical tag "release-6-3"
> is identical to what I applied as REL6_3. It would probably be
> reasonable to remove "release-6-3", if that's still possible, but
> I'm not clear on how.
You can s
At 2010-09-21 11:02:30 -0400, t...@sss.pgh.pa.us wrote:
>
> So you really do need git ignore to ignore all build products;
> otherwise you'll have lots of chatter in "git status".
Right.
I usually put build products into a top-level build directory and put
"build/" in my top-level .gitignore (but
At 2010-09-21 11:59:09 -0400, and...@dunslane.net wrote:
>
> However, that does mean losing the private commit history. I'm not
> sure much can be done about that, unless you migrate each commit
> separately, which could be painful.
It doesn't have to be painful.
Determine what patches from the o
At 2010-09-16 21:22:54 +0900, itagaki.takah...@gmail.com wrote:
>
> Please read the thread. The patch is intended to be applied after
> "sequence scan + sort for CLUSTER" patch.
Sorry. I missed that. The patch looks fine, then.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
(Sorry for the broken threading. I didn't have a convenient copy of the
original message to reply to.)
I looked at the patch and it seems quite reasonable, but two hunks of
the changes to src/backend/commands/cluster.c don't apply cleanly. I'm
not sure what version the patch was generated against,
At 2010-07-21 06:57:53 -0400, robertmh...@gmail.com wrote:
>
> Post 'em here or drop them on the wiki and post a link.
1. Clone the remote repository as usual:
git clone git://git.postgresql.org/git/postgresql.git
2. Create as many local clones as you want:
git clone postgresql foobar
At 2010-07-21 12:55:55 +0200, mag...@hagander.net wrote:
>
> We are not changing the workflow, just the tool.
OK, but I don't see why accidental merge commits need to be considered
antisocial, and banned or rebased away. Who cares if they exist? They
don't change anything you need to do to pull, c
At 2010-07-21 06:39:28 -0400, robertmh...@gmail.com wrote:
>
> Perhaps we need to write up directions on how to do that.
I'll write them if you tell me where to put them. It's trivial.
> Well, per previous discussion, we're not going to change that at this
> point, or maybe ever.
Sure. I just wa
At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote:
>
> I think there is also a committer field, but that doesn't always
> appear and I'm not clear on how it works.
There is always a committer field, and it is set sensibly as long as the
committer has user.name and user.email set correctly
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
>
> 1. Clone the origin. Then, clone the clone n times locally. This
> uses hard links, so it saves disk space. But, every time you want to
> pull, you first have to pull to the "main" clone, and then to each of
> the "slave" clones. An
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
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
(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, th
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(
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 fro
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.
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
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:
http://www.postgresq
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 no
(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
posti
(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 a
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 un
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:
http://www.postgres
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 b/sr
(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 pat
At 2009-04-13 10:40:41 -0400, t...@sss.pgh.pa.us wrote:
>
> Abhijit Menon-Sen writes:
> > [ a test whose purpose he didn't bother to describe ]
I'm sorry about that.
> What is the value of this? It seems far more likely to cause
> maintenance pain than to catch an
Sorry, I screwed up a little in sending that patch. Here it is again as
an attachment.
-- ams
diff --git a/src/test/regress/sql/defs.sql b/src/test/regress/sql/defs.sql
new file mode 100644
index 000..cf8fff3
--- /dev/null
+++ b/src/test/regress/sql/defs.sql
@@ -0,0 +1,24 @@
+-- Test pg_get_fu
From: Abhijit Menon-Sen
Thanks to Andrew Gierth for writing the function used in the test.
---
src/test/regress/expected/defs.out | 43
src/test/regress/parallel_schedule |2 +-
src/test/regress/serial_schedule |1 +
src/test/regress/sql/defs.sql
At 2009-04-11 14:08:21 -0400, t...@sss.pgh.pa.us wrote:
>
> So there's a use-case at least for allowing parameter symbols in place
> of string literals, if not fully general expressions. But again, I
> think we'd want such a thing across all utility statements that can
> take string literals, not o
Hi.
There's a TODO item about making COMMENT ON accept an expression. The
grammar change is simple (SConst|NULL_P->a_expr), but as far as I can
see, there are no similar utility commands that take expressions, and
I'm not very familiar with the planner and executor, so I could use
some advice abou
That this family of functions did not exist earlier was merely an
oversight.
Signed-off-by: Abhijit Menon-Sen
---
doc/src/sgml/func.sgml | 28
src/backend/utils/adt/acl.c | 210 ++
src/include/catalog/pg_proc.h
Hi Benedek.
At 2008-11-06 15:08:14 +0100, l...@benedekl.tvnetwork.hu wrote:
>
> I created an updated patch according to your notices.
I had a look at your updated patch, and it looks fine. I fiddled with
the documentation a little, and fixed up one place where the code had
drifted and the patch d
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 change
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-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 do
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
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:
http://www.post
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:
http://www.post
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
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 an
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
***
**
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
--- a/src/include/utils/buil
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
301 - 400 of 475 matches
Mail list logo
