Hi,
In the past I've found the error message in cases such as this somewhat
less helpful than it could be:
=# CREATE TABLE qqq (a int);
=# CREATE UNIQUE INDEX IF NOT EXISTS qqq_a_idx ON qqq(a);
=# ALTER TABLE qqq ALTER COLUMN a TYPE json USING NULL;
ERROR: data type json has no default operat
On 2015-09-01 23:19, I wrote:
Hopefully nobody minds if I slip this to the commit fest that started
today? The attached patch should address all the comments from the 9.5
cycle.
Apparently the CF app will. Meh. Whatever. Ignore then, I guess.
.m
--
Sent via pgsql-hackers mailing list (p
Hi,
Hopefully nobody minds if I slip this to the commit fest that started
today? The attached patch should address all the comments from the 9.5
cycle.
.m
*** a/src/backend/parser/analyze.c
--- b/src/backend/parser/analyze.c
***
*** 2107,2118 transformUpdateTargetList(Parse
On 8/20/15 4:25 PM, Magnus Hagander wrote:
On Aug 20, 2015 4:16 PM, "Tom Lane" wrote:
Our expectations about forward compatibility for postgresql.conf entries
have always been pretty low; even more so for not-widely-used settings.
In any case, wouldn't what you describe simply put off the pain
On 8/20/15 12:57 PM, Magnus Hagander wrote:
I mean that you could write radius_server=foo or radius_servers=foo as well
as radius_server=foo,bar and radius_servers=foo,bar. As long as you don't
specify both radius_server and radius_servers, either one of them should
accept either one server or mu
On 8/20/15 12:53 PM, Magnus Hagander wrote:
We could change it to radius_servers and radius_ports, and deprecate but
keep accepting the old parameters for a release or two.
That's one option..
To make it easy, we
make sure that both parameter names accepts the same format parameter, so
it's e
On 2015-08-20 02:29, Tom Lane wrote:
Marko Tiikkaja writes:
So I'm developing a patch to fix this issue, but I'm not
exactly sure what the configuration should look like. I see multiple
options, but the one I like the best is the following:
Add two new HBA configurati
Hi,
We use RADIUS authentication at $WORK, and it has one major flaw (well,
two, but I already fixed the other one this week): it only supports
specifying a single server, which as we might know, is bad for high
availability. So I'm developing a patch to fix this issue, but I'm not
exactly s
On 2015-08-15 17:55, I wrote:
The attached patch adds support for RADIUS passwords longer than 16 octets.
Improved the coding and comments a bit, new version attached.
.m
*** a/src/backend/libpq/auth.c
--- b/src/backend/libpq/auth.c
***
*** 2168,2173 CheckCertAuth(Port *port)
Hi,
The attached patch adds support for RADIUS passwords longer than 16 octets.
.m
*** a/src/backend/libpq/auth.c
--- b/src/backend/libpq/auth.c
***
*** 2168,2173 CheckCertAuth(Port *port)
--- 2168,2174
#define RADIUS_VECTOR_LENGTH 16
#define RADIUS_HEADER_LENGTH 20
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer num_nulls() over that.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-08-12 7:35 PM, Pavel Stehule wrote:
maybe nulls_count ?
we have regr_count already
But that's an aggregate as well..
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-08-12 7:23 PM, Greg Stark wrote:
On Wed, Aug 12, 2015 at 6:18 PM, Marko Tiikkaja wrote:
Will finish this up for the next CF, unless someone wants to tell me how
stupid this idea is before that.
I'm kind of puzzled what kind of schema would need this.
The first example I could
Hi,
I'd like to suggest $SUBJECT for inclusion in Postgres 9.6. I'm sure
everyone would've found it useful at some point in their lives, and the
fact that it can't be properly implemented in any language other than C
I think speaks for the fact that we as a project should provide it.
A quic
On 8/12/15 9:36 AM, Pavel Stehule wrote:
So, there is common agreement on this version.
There are several instances of double semicolons. Also,
PsqlSettings.show_context doesn't look like a boolean to me. For
SHOW_CONTEXT, it would be good if the documentation mentioned the
default value.
On 8/10/15 1:29 PM, Andres Freund wrote:
On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote:
+ if (confirmed_flush_lsn != InvalidTransactionId)
+ values[i++] = LSNGetDatum(confirmed_flush_lsn);
+ else
+ nulls[i++] = true
On 7/20/15 6:02 PM, Corey Huinker wrote:
By using only(a.name_of_the_thing) we'd have a bit more clarity that the
author expected all of those values to be the same across the aggregate
window, and discovering otherwise was reason enough to fail the query.
*IF* we're considering adding these to
On 2015-07-08 14:57, I wrote:
Adding this one to the next commit fest, but any feedback welcome in the
meanwhile.
Forgot to change PG_GET_REPLICATION_SLOTS_COLS; fixed in the attached patch.
.m
diff --git a/src/backend/catalog/system_views.sql
b/src/backend/catalog/system_views.sql
index e82
Hi,
I had some trouble today with a misbehaving logical replication client
which had confirmed a flush of an LSN far into the future. Debugging it
was a bit of a pain for a number of reasons, but I think the most
important one was that confirmed_flush isn't exposed in
pg_stat_replication_slo
Hi,
One of the debug messages related to logical replication could be more
helpful than it currently is. The attached patch reorders the two
operations to make it so.
Please consider patching and back-patching.
.m
diff --git a/src/backend/replication/logical/logical.c
b/src/backend/replic
On 7/2/15 9:15 AM, Etsuro Fujita wrote:
> While working on the foreign-join-pushdown issue, I noticed that in READ
> COMMITTED isolation level it's possible that the result of SELECT ...
> ORDER BY ... FOR UPDATE is not sorted correctly due to concurrent
> updates that replaced the sort key columns
On 6/11/15 11:41 AM, Naoya Anzai wrote:
> This can change the input of the 24 characters to the only 4 characters!
>
> Image.
> --
> naoya=# \bid
> Backend Process ID
> pid
> --
> 1716
> (1 row)
> ---
>
> How do you like it?
Seems easier to set thi
On 5/27/15 12:39 PM, Jordan Gigov wrote:
I found myself in need of triggers that are run only once per transaction,
rather than per row or statement within the transaction. Meaning it will
always be deferred and never called twice for the same transaction.
What's the use case?
.m
--
Sent vi
On 5/20/15 5:21 PM, Robert Haas wrote:
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs wrote:
That's a reasonable argument. So +1 to protocol from me.
To satisfy Tom, I think this would need to have two modes: one where the
session can never be reset, for ultra security, and one where the session
On 2015-05-20 00:59, Jim Nasby wrote:
I find it annoying to have to specifically exclude pg_backend_pid() from
pg_stat_activity if I'm trying to kill a bunch of backends at once, and
I can't think of any reason why you'd ever want to call a pg_cancel_*
function with your own PID.
That's a rathe
On 5/19/15 3:04 PM, Thom Brown wrote:
If you want the delta, you'll have to resort to a CTE:
e.g.
# WITH newvals AS (
INSERT INTO test (name, age) VALUES ('James', 45)
ON CONFLICT (name)
DO UPDATE SET age = EXCLUDED.age
RETURNING *)
SELECT n.name, o.age as "old.age"
On 2015-05-18 22:10, Josh Berkus wrote:
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
In the context of splitting shallow and deep merge into two operators, I
think + is better for shallow and || better for deep. The reason for +
is because many programming languages have this behavior. If I see th
Hi hackers,
Any chance to get this fixed in time for 9.1.16?
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-04-28 19:43, Robert Haas wrote:
I guess
the root of the problem is that PL/plgsql's cache invalidation logic
only considers the pg_proc row's TID and xmin when deciding whether to
recompile. For base types that's probably OK, but for composite
types, not so much.
Thoughts?
We recently
Hi Pavel,
This doesn't seem to be what I thought we had agreed on. For example:
=# create function barf() returns void as $$ begin raise notice without
context 'hello world'; end $$ language plpgsql;
CREATE FUNCTION
=# create function foof() returns void as $$ begin perform barf(); end
$$ la
On 4/27/15 6:08 PM, FabrÃzio de Royes Mello wrote:
On Sun, Apr 26, 2015 at 4:19 AM, Pavel Stehule
wrote:
I reduced this patch, little bit cleaned - now it is based on plpgsql GUC
display_context_min_messages - like client_min_messages, log_min_messages.
What you think just "context_min_messag
On 4/2/15 9:37 AM, Pavel Stehule wrote:
estate->err_text = stmt->elog_level == ERROR ? estate->err_text :
raise_skip_msg ;
Can we do this simple change? It will produce a stackinfo for exceptions
and it will not to make mad developers by lot of useless content.
I'm not sure everyone agrees w
On 3/18/15 12:27 PM, Pavel Stehule wrote:
On 3/17/15 8:06 PM, Alvaro Herrera wrote:
My main question regarding this patch is whether the behavior with MD
arrays is useful at all. Suppose I give it this:
alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}',
3);
array_o
Hi,
My colleague Per Lejontand brought to my attention that when dumping
views with circular dependencies from a postgres version older than 9.4
using a recent pg_dump, the SQL looks something like the following:
create table qwr();
create rule "_RETURN" as on select to qwr do instead sel
On 2015-03-06 01:28, Tom Lane wrote:
In bug #12832 Marko Tiikkaja points out that commit
7b583b20b1c95acb621c71251150beef958bb603 created a rather unnecessary
dump failure hazard, since it applies pg_get_function_identity_arguments()
to every function in the database, even those that won'
On 3/4/15 6:19 PM, I wrote:
On 3/4/15 5:26 PM, Tom Lane wrote:
It was considered to be a bug fix; more, given the few complaints about
the clearly-broken old behavior, we thought it was a fix that would affect
few people, and them positively.
Yeah, but these things usually go the other way. "
On 3/4/15 5:26 PM, Tom Lane wrote:
Robert Haas writes:
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja wrote:
I'm not sure how changing behavior like this in a minor release was
considered acceptable.
I'm guessing that the fact that it changes behavior in cases like this
wasn&#x
Hi,
Andres asked me on IRC to report this here. Since we upgraded our
standby servers to 9.1.15 (though the master is still running 9.1.14),
we've seen the error in $SUBJECT a number of times. I managed to
reproduce it today by running the same query over and over again, and
attached is the
Hi,
Commit 79af9a1d2668c9edc8171f03c39e7fed571eeb98 changed xpath handling
with regard to namespaces, and it seems to be fixing an actual issue.
However, it was also backpatched to all branches despite it breaking for
example code like this:
do $$
declare
_x xml;
begin
_x := (xpath('/x:Foo/x
On 2/13/15 8:52 AM, Michael Paquier wrote:
On Sun, Nov 23, 2014 at 8:23 PM, David Rowley wrote:
As the patch stands there's still a couple of FIXMEs in there, so there's
still a bit of work to do yet.
Comments are welcome
Hm, if there is still work to do, we may as well mark this patch as
re
On 2015-02-08 09:56, Shay Rojansky wrote:
More to the point, doesn't max_rows=1 have exactly the same dangers as
LIMIT 1? The two seem to be identical, except that one is expressed in
the
SQL query and the other at the network protocol level.
The planner does not have access to network proto
On 2/5/15 4:48 PM, Jan Wieck wrote:
What the script does is to encode a small string with pgp_sym_encrypt()
and then repeatedly try to decrypt it with different "wrong" passwords.
The expected error message for that is of course
"Wrong key or corrupt data".
Every now and then, I get a dif
On 2/4/15 12:36 PM, Stephen R. van den Berg wrote:
Marko Tiikkaja wrote:
This seems to be a common pattern, and I think it's a *huge* mistake
to specify maxrows=1 and/or ignore rows after the first one in the
driver layer. If the user says "give me the only row returned by
I guess
On 2/4/15 12:27 PM, Andres Freund wrote:
On 2015-02-04 12:23:51 +0100, Marko Tiikkaja wrote:
On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
If you know beforehand the query might generate more than one row (SELECT)
yet you also know that you are not interested in those, then maxrows=1
is
On 2/4/15 12:31 PM, Andres Freund wrote:
On 2015-02-04 12:25:04 +0100, Marko Tiikkaja wrote:
On 2/4/15 12:17 PM, Stephen R. van den Berg wrote:
I believe he's talking about the network protocol of postgreSQL, not
about query optimisation (as you do).
I don't believe so.
Did yo
On 2/4/15 12:17 PM, Stephen R. van den Berg wrote:
Andres Freund wrote:
On 2015-02-03 12:26:33 +0100, Shay Rojansky wrote:
find a way to execute a query but without fetching any rows. The Execute
message has a maximum result-row count, but zero is documented to mean
"fetch all rows".
Is this
On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
If you know beforehand the query might generate more than one row (SELECT)
yet you also know that you are not interested in those, then maxrows=1
is best; then again, modifying the query to include a LIMIT 1 is even
better, in which case maxrows
On 2/3/15 4:04 PM, David Fetter wrote:
On Mon, Feb 02, 2015 at 08:56:19PM -, Greg Sabino Mullane wrote:
Robert Haas wrote:
but there are times when it's easier to find out what release
introduced a feature by looking at the release notes, and it's
certainly more useful if you want to send a
On 1/26/15 1:44 PM, Pavel Stehule wrote:
2015-01-26 13:39 GMT+01:00 Marko Tiikkaja :
On 1/26/15 1:14 PM, Pavel Stehule wrote:
I afraid about some unexpected side effects of your proposal if somebody
mix languages - these side effects should not be critical
I have no idea what you're ta
On 1/26/15 1:14 PM, Pavel Stehule wrote:
2015-01-26 13:02 GMT+01:00 Marko Tiikkaja :
I can see where it's a lot nicer not to have the context visible for
people who only care about the contents of the message, but the way it's
done in PL/PgSQL right now is just not good enough. On
On 1/22/15 6:03 PM, Pavel Stehule wrote:
2015-01-22 12:37 GMT+01:00 Marko Tiikkaja :
Or is that a stupid idea? I just think hacking libpq for something like
this is a huge overkill.
I don't think so only plpgsql solution is satisfactory idea. There are
some mix plpgsql / p
Hello,
I just heard that there's going to be a fifth CF for 9.5 so I'm trying
to gather all the patches I'd like to see in 9.5..
On 8/23/13 10:36 AM, I wrote:
My opinion at this very moment is that we should leave the the DEFAULT
verbosity alone and add a new one (call it COMPACT or such) wit
On 2015-01-08 01:13, Merlin Moncure wrote:
Interestingly, the following query works (it didn't used to):
select from generate_series(1, 1);
Was this intentional?
See 1b4f7f93b4693858cb983af3cd557f6097dab67b
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On 1/7/15 6:22 PM, Alvaro Herrera wrote:
We're waiting for an updated version here, right?
Yeah. (The CF entry is also set to Waiting on Author, which seems
appropriate.)
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On 2014-12-26 17:23, Kevin Grittner wrote:
Are there any objections to generating a write conflict instead of
a duplicate key error if the duplicate key was added by a
concurrent transaction? Only for transactions at isolation level
REPEATABLE READ or higher?
Is it possible to distinguish betw
On 12/19/14 3:27 PM, Stephen Frost wrote:
We'd have to coach our users to
constantly be tweaking the enable_parallel_query (or whatever) option
for the queries where it helps and turning it off for others. I'm not
so excited about that.
I'd be perfectly (that means 100%) happy if it just defau
On 12/17/14 5:37 PM, Heikki Linnakangas wrote:
On 12/15/2014 02:43 AM, Marko Tiikkaja wrote:
The syntax is:
DROP PRIVILEGES OWNED BY role [, ...]
DROP seems like the wrong verb here. DROP is used for deleting objects,
while REVOKE is used for removing permissions from them. REVOKE
On 12/16/14 11:26 AM, Mark Cave-Ayland wrote:
On 15/12/14 19:27, Robert Haas wrote:
So, there are certainly some large patches that do that, and they
typically require a very senior reviewer. But there are lots of small
patches too, touching little enough that you can learn enough to give
them
Hi,
This week I had a problem where I wanted to drop only the privileges a
certain role had in the system, while keeping all the objects. I
couldn't figure out a reasonable way to do that, so I've attached a
patch for this to this email. Please consider it for inclusion into
9.5. The synta
On 11/26/14 8:55 AM, Pavel Stehule wrote:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
I think so. The way I would use this function is to put expensive
checks into strategic locations which would only run when developing
locally (and ad
On 2014-11-22 18:02, Tom Lane wrote:
Marko Tiikkaja writes:
A common mistake is to try and qualify column references on the LHS of
SET in UPDATE. The error message can be a bit cryptic at times, too.
Perhaps, but this hint is not much of an improvement:
HINT: Target column references in
On 2014-11-22 05:11, Peter Geoghegan wrote:
On Fri, Nov 21, 2014 at 7:49 PM, Marko Tiikkaja wrote:
A common mistake is to try and qualify column references on the LHS of SET
in UPDATE.
I think that this is a good idea, but as written the patch doesn't
handle aliases correctly:
pos
On 2014-11-22 12:20 PM, Pavel Stehule wrote:
2. missing table function with all settings. Like SHOW ALL, but with
filtering possibility
What's wrong with pg_settings?
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
Hi,
A common mistake is to try and qualify column references on the LHS of
SET in UPDATE. The error message can be a bit cryptic at times, too.
I've attached a patch to try and improve the situation a bit:
=# create table foo(bar int);
CREATE TABLE
=# update foo set foo.bar = 1;
ERROR: col
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane :
Robert Haas writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension of RAISE; it adds all sorts of semantic issues. (In
parti
On 11/19/14 3:38 PM, Albe Laurenz wrote:
I think that should be forbidden, because it is very likely to corrupt
the index. I expect the objection that this would break valid use cases
where people know exactly what they are doing, but I believe that this
is a footgun for inexperienced users that
On 11/5/14, 7:36 PM, Josh Berkus wrote:
On 11/04/2014 04:04 PM, Marko Tiikkaja wrote:
In my example, the input is a "timestamptz", and the output is converted
to the target time zone the same way timestamptz_out() does, except
based on the input timezone instead of TimeZone.
Not su
On 11/5/14, 12:59 AM, Tom Lane wrote:
Marko Tiikkaja writes:
So I got into thinking whether it would make sense to provide a new
function, say, to_char_at_timezone() to solve this problem. For example:
...
Any thoughts? The patch is quite trivial.
I'm not convinced that it'
Hi,
9.4 FINALLY added the UTC offset formatting pattern to to_char().
However, it falls a bit short in the sense that it's always the time
zone offset according to the effective TimeZone value. This has a few
issues as far as I can tell:
1) It's not truly controlled by the query which pro
On 11/2/14, 10:34 PM, Noah Misch wrote:
On Sun, Nov 02, 2014 at 05:10:25AM +0100, Marko Tiikkaja wrote:
*** a/contrib/pgcrypto/pgp-decrypt.c
--- b/contrib/pgcrypto/pgp-decrypt.c
***
*** 1069,1075 pgp_skip_packet(PullFilter *pkt)
while (res > 0)
Hi,
Patch attached to fix some sillyness in pgp_expect_packet_end() and
pgp_skip_packet(). Will add to the next commitfest unless someone picks
this one up before that.
.marko
*** a/contrib/pgcrypto/pgp-decrypt.c
--- b/contrib/pgcrypto/pgp-decrypt.c
***
*** 1069,1075 pgp_sk
Hi Atri,
Sorry for the delay. With pgconf.eu and all, it's been very hard to
find the time to look at this.
On 10/15/14, 10:02 AM, Atri Sharma wrote:
Please find attached a patch which implements support for UPDATE table1
SET(*)=...
The patch supports both UPDATE table SET(*)=(a,b,c) and UPD
Hi,
On 10/17/14, 9:56 PM, Jeff Janes wrote:
This patch needs a rebase now that the armor header patch has been
committed.
Thanks. Will fix that shortly.
I'm guessing there's no need to bump the pgcrypto version to 1.3, since
there hasn't been a release with the 1.2 version?
.marko
--
S
Hi,
Commit 32984d8fc3dbb90a3fafb69fece0134f1ea790f9 forgot to change the
filename in the comment in contrib/pgcrypto/pgcrypto--1.2.sql. Trivial
patch attached.
.marko
*** a/contrib/pgcrypto/pgcrypto--1.2.sql
--- b/contrib/pgcrypto/pgcrypto--1.2.sql
***
*** 1,4
! /* contrib/
On 10/18/14, 5:46 PM, Tom Lane wrote:
Marko Tiikkaja writes:
Yes, exactly; if I had had the option to disable the index from the
optimizer's point of view, I'd have seen that it's not used for looking
up any data by any queries, and thus I would have known that I can
safely
On 10/18/14, 4:33 PM, Bruce Momjian wrote:
On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
Another idea had was some way to tell the optimizer not to use that
particular index for stats lookups, but probably the use case for
such a feature would be a bit narrow.
Well, if the
On 10/18/14, 5:16 AM, Tom Lane wrote:
BTW, on re-reading that code I notice that it will happily seize upon
the first suitable index ("first" in OID order), regardless of how many
lower-order columns that index has got. This doesn't make any difference
I think for get_actual_variable_range's own
On 10/18/14, 12:15 AM, Tom Lane wrote:
Marko Tiikkaja writes:
I think there's a big difference between "this index was used to look up
stuff for planning" and "this index was used to answer queries quickly".
I think that's utter nonsense.
Well you prob
On 10/17/14, 11:59 PM, Tom Lane wrote:
Marko Tiikkaja writes:
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
So what I'd like to have is a way to be able to distinguish between
indexes being used to answer queries, and ones being only used for stats
lookups during pla
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. Ho
Hi,
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However, after looking into our queries more closely, it turns
o
On 10/17/14 5:03 PM, Merlin Moncure wrote:
Hm, I didn't understand your objection:
So e.g.:
UPDATE foo f SET f = ..;
would resolve to the table, despite there being a column called "f"?
That would break backwards compatibility.
That's not correct: it should work exactly as 'select' does;
On 10/17/14 4:15 PM, Merlin Moncure wrote:
Any particular reason why you couldn't have just done:
UPDATE table1 SET * = a,b,c, ...
That just looks wrong to me. I'd prefer (*) = .. over that any day.
UPDATE table1 t SET t = (SELECT (a,b,c)::t FROM...);
seems cleaner than the proposed synt
On 10/12/14, 2:36 PM, Matthew Woodcraft wrote:
On 2014-10-10 19:44, Kevin Grittner wrote:
To restate: to do so is conflating the logical definition of the
database with a particular implementation detail. As just one
reason that is a bad idea: we can look up unique indexes on the
specified colu
On 10/7/14, 9:11 AM, Feike Steenbergen wrote:
Perhaps I am the only one using autocommit-off mode
You most definitely aren't.
and we shouldn't put effort
into fixing this?
It's not clear to me that this is fixing a problem, to be honest. If
you're running autocommit=off, you have an expec
code from the patch rejected before.
Committed with minor changes
Hmm, the CommitFest app lists Marko Tiikkaja as the reviewer, but I
can't find his review anywhere...
Maybe he have no time to review it.
Yes, Heikki picked this up before I had a chance to review it. Sorry
about
On 10/2/14 1:47 PM, Heikki Linnakangas wrote:
I looked at this briefly, and was surprised that there is no support for
signing a message without encrypting it. Is that intentional? Instead of
adding a function to encrypt and sign a message, I would have expected
this to just add a new function fo
On 10/1/14 1:01 PM, Heikki Linnakangas wrote:
On 10/01/2014 11:58 AM, Marko Tiikkaja wrote:
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
We have two options:
1. Throw an error if there are any non-ASCII characters in the key/value
arrays.
2. Don't convert them to UTF-8, but use the cu
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
I spent a little time cleaning up the regression tests and docs, and
ended up with the attached. But then I realized that there's a problem
with UTF-8 conversion in the armor() function. It returns the armored
blob as text, but forcibly converts the
On 9/30/14 5:17 PM, Heikki Linnakangas wrote:
I'm actually now leaning towards providing just a single function,
pgp_armor_headers(text, key OUT text, value OUT text), which returns all
the keys and values. That gives maximum flexibility, and leaves it up to
the user to decide what to do with dup
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which returned the last instance of the key. But
On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
Thanks! I found the pgp_extract_armor_headers()'s signature quite weird,
so I simplified that by making it always return arrays of keys and
values. The callers is now responsible for returning all the keys
(pgp_armor_header_keys) or finding the single
On 9/28/14, 11:53 AM, Shay Rojansky wrote:
I would, in theory, love to switch the entire thing to binary and thereby
avoid all textual parsing once and for all. If I understand correctly, this
means all queries must be implemented as extended queries, with numerous
extra client-server roundtrips
Hi,
On 9/25/14, 3:56 PM, I wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
Are you planning to post the main patch rebased on top of this soon? As
in the next day or two? Otherwise I'll mark this as "Returned with
feedback" for this commitfest.
Yes. With good luck I'll get you a rebased
On 9/25/14 4:08 PM, Heikki Linnakangas wrote:
On 09/25/2014 04:56 PM, Marko Tiikkaja wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
It might've been a tad more efficient to return
the StringInfo buffer directly from pgp_armor/dearmor
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
OK, I've attemped to do that in the attached. I'm pretty sure I didn't
get all of the overflows right, so someone should probably take a really
good look at it. (I'm not too confide
On 9/22/14 10:57 AM, Andres Freund wrote:
On 2014-09-22 07:42:01 +0100, Daniele Varrazzo wrote:
Is this intentional? Is there a better way to check for a broken connection?
Note that the libpq code treats connection resets differently from
other, arbitrary, errors:
I.e. if the kernel returns
On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
wrote:
Why are you using close() instead of PQfinish()?
Because I'm testing for an error, please read my message and the
original bug report.
I read
On 2014-09-19 8:20 PM, Merlin Moncure wrote:
actually, this trick *only* works during json serialization -- it
allows control over the column names that row() masks over. trying to
expand (tup).* still gives the dreaded "ERROR: record type has not
been registered". That's because this works:
On 2014-09-18 10:29 PM, Vik Fearing wrote:
On 09/18/2014 10:16 PM, Hannu Krosing wrote:
I guess it proves (a little) that WITH is the right place to do these
kind of things ...
I've been wanting this syntax for a few years now, so I certainly vote
for it.
I've also been wanting do to somethi
101 - 200 of 661 matches
Mail list logo
