...@huawei.com
--
Álvaro Hernández Tortosa
---
NOSYS
Networked Open SYStems
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Peter, Dimitri, thank you for your comments.
On 03/12/13 22:27, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
On 12/1/13, 2:24 PM, Álvaro Hernández Tortosa wrote:
IMHO, defining a new syntax for the postgreql.conf file format,
that is suitable
On 04/12/13 16:51, Peter Eisentraut wrote:
On 12/4/13, 1:42 AM, Álvaro Hernández Tortosa wrote:
IMHO, a data structure like the above would be completely
self-contained and allow any autoconfiguring tool or GUI tool to be
easily created, if the syntax is programmable. It would certainly
On 04/12/13 19:49, Peter Eisentraut wrote:
On 12/4/13, 11:22 AM, Álvaro Hernández Tortosa wrote:
Would it be well-received a new file format that keeps it simple for
both hand editing and generation of the configuration, and at the same
time offers the features I have mentioned?
I don't see
On 04/12/13 20:44, Peter Eisentraut wrote:
On 12/4/13, 2:02 PM, Álvaro Hernández Tortosa wrote:
So optional fields are either purely optional (i.e., only for tools
that want to use them; everyone else may ignore, but preserve, them) and
some other are just NULLABLEs, depending
On 06/12/13 04:47, Peter Eisentraut wrote:
On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote:
The tradeoff seems quite positive to me. I see no strong
reasons why
not do it... am I missing something?
I don't buy your argument. You say, if we make this change
On 06/12/2013 22:59, Peter Eisentraut wrote:
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote:
What I've been trying to do is summarize what has already been
discussed here and propose a solution. You say that you can already do
those thisngs, but that's not what I have read here
On 06/12/2013 19:11, David Johnston wrote:
Álvaro Hernández Tortosa wrote
Note that you are not required to maintain your configuration data in a
postgresql.conf-formatted file. You can keep it anywhere you like, GUI
around in it, and convert it back to the required format. Most
On 09/12/13 18:26, Greg Stark wrote:
On Sat, Dec 7, 2013 at 3:28 AM, Álvaro Hernández Tortosa a...@nosys.es wrote:
Right now, writing such a tool in a generic way gets so bogged down
just in parsing/manipulating the postgresql.conf file that it's hard to
focus on actually doing the tuning
On 09/12/13 18:00, Robert Haas wrote:
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
I think both could be used a lot, editing directly a rich configuration
file or using a GUI tool. I'm trying to suggest supporting both.
I don't really understand how
On 13/12/13 04:11, Greg Stark wrote:
On 12 Dec 2013 04:20, Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es wrote:
Thanks, Greg. I've been going through those threads, they are
quite interesting. I didn't find an answer, though, about my question:
why parsing
On 01/09/14 14:27, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.
...
Official implementation of plpgsql2 can be very
On 01/09/14 20:42, Tom Lane wrote:
=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= a...@nosys.es writes:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader scope. What would attract most
users? Would it bring non postgres users
On 01/09/14 21:08, Pavel Stehule wrote:
2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On 01/09/14 20:42, Tom Lane wrote:
=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= a...@nosys.es
mailto:a...@nosys.es writes
On 01/09/14 21:52, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader scope. What would attract most
users? Would it bring non
On 01/09/14 23:31, Marko Tiikkaja wrote:
On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote:
No, really: if there is a new version of a language, which
modifies the current syntax of plpgsql; if plpgsql is already very
similar to PL/SQL: why not rather than coming up with a new
On 01/09/14 23:46, David G Johnston wrote:
Álvaro Hernández Tortosa wrote
On 01/09/14 21:52, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa lt;
aht@
gt; wrote:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan
On 02/09/14 05:24, Craig Ringer wrote:
I couldn't disagree more.
If we were to implement anything, it'd be PL/PSM
(http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and
quirky as anything else the SQL committee has brought forth, but it's at
least a standard(ish) language.
So
On 02/09/14 06:40, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
If someone came up with a convincing PL/SQL compatibility layer then
it'd be worth considering adopting - when it was ready. But of course,
anyone who does the work for that is quite likely to want to sell it to
On 02/09/14 11:34, Mark Kirkwood wrote:
On 02/09/14 21:25, Álvaro Hernández Tortosa wrote:
On 02/09/14 05:24, Craig Ringer wrote:
I couldn't disagree more.
If we were to implement anything, it'd be PL/PSM
(http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and
quirky
On 02/09/14 11:31, Pavel Stehule wrote:
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On 02/09/14 05:24, Craig Ringer wrote:
I couldn't disagree more.
If we were to implement anything, it'd be PL/PSM
(http
On 02/09/14 11:44, Pavel Stehule wrote:
For 9.4, we have the media already saying Postgres has NoSQL
capabilities (which is only partially true). For x.y we could
have the media saying Postgres adds Oracle compatibility (which
would be only partially true). But that
On 02/09/14 11:56, Pavel Stehule wrote:
2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On 02/09/14 11:31, Pavel Stehule wrote:
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On 02
On 02/09/14 12:46, Marko Tiikkaja wrote:
On 9/2/14 11:40 AM, Álvaro Hernández Tortosa wrote:
If we are to have another plpgsql-like language (like plpgsql2)
and
we could design it so it would attract many many users (let's not forget
that Oracle may have around two orders of magnitude
On 02/09/14 17:03, Hannu Krosing wrote:
On 09/02/2014 11:52 AM, Álvaro Hernández Tortosa wrote:
On 02/09/14 11:44, Pavel Stehule wrote:
For 9.4, we have the media already saying Postgres has
NoSQL capabilities (which is only partially true). For x.y we
could have
On 02/09/14 18:20, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com wrote:
Sorry for being unclear, I didn't mean to suggest the main concern is
updating *all* rows.
The main concern is when you have a rather complex
On 02/09/14 18:33, Hannu Krosing wrote:
On 09/02/2014 06:27 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
We are definitely worse. This is the problem, we only look to our own
belly bottom (if this expression exists in English
On 02/09/14 23:11, David Johnston wrote:
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent quite a few man-years
on their
On 02/09/14 23:34, Joshua D. Drake wrote:
On 09/02/2014 02:11 PM, David Johnston wrote:
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent
On 03/09/14 00:41, Joshua D. Drake wrote:
On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote:
Yeah, we differ there. I think having an Oracle compatibility layer
in PostgreSQL would be the-next-big-thing we could have. Oracle is has
orders of magnitude bigger user base than postgres
On 02/09/14 04:47, Dobes Vandermeer wrote:
Same idea as PgBouncer or PgPool. The advantage over hacking
PgBouncer/PgPool for the job is that Tomcat can already do a lot
of what
you want using built-in, pre-existing functionality. Connection pool
management, low level
On 03/09/14 15:24, Joshua D. Drake wrote:
On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote:
It's not copying. It's easying a path for others to migrate and
come to Postgres.
I'm interested why you are more interested in MSSQL. My reasons for
being interested in Oracle
On 04/09/14 18:02, Craig Ringer wrote:
On 09/04/2014 06:48 AM, Joshua D. Drake wrote:
On 09/03/2014 11:48 AM, Robert Haas wrote:
Anyway, to get back around to the topic of PL/SQL compatibility
specifically, if you care about that issue, pick one thing that exists
in PL/SQL but not in
On 03/09/14 20:48, Robert Haas wrote:
On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
Yeah, we differ there. I think having an Oracle compatibility layer in
PostgreSQL would be the-next-big-thing we could have. Oracle is has orders
of magnitude bigger user
select, I'd have expected to have no rows. If a SELECT 1
is issued after BEGIN, there are no rows found.
--
Álvaro Hernández Tortosa
---
8Kdata
in the concurrency control chapter
of the manual.
Sure, there are, that was the link I pointed out, but I found no
explicit mention to the fact that I'm raising here.
Regards,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 04/11/14 09:07, Craig Ringer wrote:
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any
objection to do this?
If we go that route we should also mention that now() will no longer
be doing what you probably hope it would
On 06/11/14 00:42, Robert Haas wrote:
On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa a...@8kdata.com
wrote:
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any* query
within the first transaction
On 06/11/14 02:06, Jim Nasby wrote:
On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote:
On 05/11/14 17:46, Jim Nasby wrote:
On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote:
Should we improve then the docs stating this more clearly? Any
objection to do this?
If we go that route
On 06/11/14 15:00, Kevin Grittner wrote:
Álvaro Hernández Tortosa a...@8kdata.com wrote:
There has been two comments which seem to state that changing this
may introduce some performance problems and some limitations when you
need to take out some locks. I still believe, however
On 07/11/14 22:02, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and that is the point at
which the snapshot is obtained.
But there is so much evidence to the
to raise, globally, some millions
per year to stably, and permanently, fund this community-guided
development and have our best developers devoted 100% to PostgreSQL.
Regards,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers
. In the graphs you can't even realize there were more tables
been created. At around 8K tables from the theoretical limit of 4B oids
consumed, the process basically stopped (doing more insertions).
Hope that this information helps.
Best regards,
Álvaro
--
Álvaro Hernández Tortosa
On 11/02/15 02:30, Tom Lane wrote:
[...]
I think it would be wise to take two steps back and think about what
the threat model is here, and what we actually need to improve.
Offhand I can remember two distinct things we might wish to have more
protection against:
* scraping of passwords off
On 24/03/15 20:56, Bruce Momjian wrote:
On Fri, Mar 20, 2015 at 04:43:42PM -0400, Bruce Momjian wrote:
On Sat, Nov 8, 2014 at 09:53:18PM +0100, Álvaro Hernández Tortosa wrote:
On 07/11/14 22:02, Greg Sabino Mullane wrote:
Kevin Grittner wrote:
I think most people have always assumed
On 25/04/15 06:39, Jim Nasby wrote:
On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote:
On 24/04/15 05:24, Tom Lane wrote:
...
TBH, I've got very little enthusiasm for fixing this given the number
of reports of trouble from the field, which so far as I recall is zero.
Álvaro's case came up
On 24/04/15 05:24, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Bruce Momjian (br...@momjian.us) wrote:
On Sun, Feb 1, 2015 at 03:54:03PM +0100, Álvaro Hernández Tortosa wrote:
The problem here is that performance degrades exponentially, or
worse. Speaking here from experience
e wrapping)
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 13/10/15 16:24, Andres Freund wrote:
On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
On 13/10/15 04:40, Tom Lane wrote:
I'm with Robert on the idea that commit log entries need to be
limited-width. I personally format them to 75 characters, so that
git_changelog's output
so I have nothing else to add :)
Best,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ort is on the same boat.
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
format. Apart from the chosen format, others may be provided as an
alternative using different data formats. Or alternatives (like
compressed text json). Of course, this may be better suited for a next
GSoC project, of course.
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Se
t under the GSoC student's control.
Agreed :)
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21/02/16 21:15, Heikki Linnakangas wrote:
On 19/02/16 10:10, Álvaro Hernández Tortosa wrote:
Oleg and I discussed recently that a really good addition to a
GSoC
item would be to study whether it's convenient to have a binary
serialization format for jsonb over the wire. Some argue
approaches are sometimes "very academical", but studying
them doesn't hurt either :)
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ords: what is the API surface exposed by PostgreSQL to
extension developers? The assumption is that no PostgreSQL code should
be modified, just adding your own and calling existing funcitons.
Thanks,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing l
On 27/02/16 15:01, Fabrízio de Royes Mello wrote:
On Sat, Feb 27, 2016 at 10:37 AM, Álvaro Hernández Tortosa
<a...@8kdata.com <mailto:a...@8kdata.com>> wrote:
>
>
> Hi.
>
> I have a newbie question for extension development. Extensions
provide an entry
On 27/02/16 15:10, Chapman Flack wrote:
On 02/27/16 08:37, Álvaro Hernández Tortosa wrote:
In other words: what is the API surface exposed by PostgreSQL to
extension developers? The assumption is that no PostgreSQL code should be
modified, just adding your own and calling existing
parts of the
API. If anyone could help me here, please let me know.
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
On 17/02/16 08:40, Amit Langote wrote:
Hi Shubham,
On 2016/02/17 16:27, Shubham Barai wrote:
Hello everyone,
I am currently pursuing my bachelor of engineering in computer science
at Maharashtra
Institute of Technology, Pune ,India. I
point of an "API".
Regards,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
On 15/03/16 13:02, Corey Huinker wrote:
Over the past few months, I've been familiarizing myself with postgres
server side programming in C.
My attempts to educate myself were slow a
On 23/03/16 01:56, Amit Langote wrote:
On 2016/03/23 9:19, Álvaro Hernández Tortosa wrote:
- Regarding GSoC: it looks to me that we failed to submit in time. Is this
what happened, or we weren't selected? If the former (and no criticism
here, just realizing a fact) what can we do next year
On 22/02/16 23:23, Álvaro Hernández Tortosa wrote:
On 22/02/16 05:10, Tom Lane wrote:
Heikki Linnakangas <hlinn...@iki.fi> writes:
On 19/02/16 10:10, �lvaro Hernández Tortosa wrote:
Oleg and I discussed recently that a really good addition to a GSoC
item would be to study whethe
are explained here:
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster
Regards,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
ry welcome!
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.0 will come with amazing features, because version is
bumped from 9.6".
So +1 to call 10.0 the next version and 11.0 the one after that.
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 15/05/16 14:42, Magnus Hagander wrote:
On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa
<a...@8kdata.com <mailto:a...@8kdata.com>> wrote:
On 14/05/16 20:02, Petr Jelinek wrote:
+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
It wi
worse: I've been told that a company was using "PostgreSQL
8.5" ^_^
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
expensive, or
dropping data).
What would it take to support it? Isn't the varlena header
propagated everywhere, which could help infer the real length of the
string? Any pointers or suggestions would be welcome.
Thanks,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
, than even implementing a new datatype based on bytea
but that would use the text IO functions to show up as text (not
send/recv) would neither work, right?
Thanks for the input,
Álvaro
--
Álvaro Hernández Tortosa
---
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-h
On 03/08/16 17:47, Kevin Grittner wrote:
On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa <a...@8kdata.com>
wrote:
What would it take to support it?
Would it be of any value to support "Modified UTF-8"?
https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8
On 03/08/16 18:35, Geoff Winkless wrote:
On 3 August 2016 at 15:54, Álvaro Hernández Tortosa <a...@8kdata.com> wrote:
Given that 0x00 is a perfectly legal UTF-8 character, I conclude we're
strictly non-compliant.
It's perhaps worth mentioning that 0x00 is valid ASCII too, and
Post
On 03/08/16 20:14, Álvaro Hernández Tortosa wrote:
On 03/08/16 17:47, Kevin Grittner wrote:
On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
What would it take to support it?
Would it be of any value to support "Modified UTF
On 03/08/16 21:31, Geoff Winkless wrote:
On 3 August 2016 at 20:13, Álvaro Hernández Tortosa <a...@8kdata.com> wrote:
Yet they are accepted by Postgres
(like if Postgres would support Modified UTF-8 intentionally). The caracter
in psql does not render as a nul but as this symb
On 03/08/16 21:42, Geoff Winkless wrote:
On 3 August 2016 at 20:36, Álvaro Hernández Tortosa <a...@8kdata.com> wrote:
Isn't the correct syntax something like:
select E'\uc080', U&'\c080';
?
It is a single character, 16 bit unicode sequence (see
https://www.postgresq
On 10/04/17 14:57, Heikki Linnakangas wrote:
On 04/07/2017 01:13 AM, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
I don't see it. The message AuthenticationSASL.String could
contain a
CSV of the SCRAM protocols sup
On 10/04/17 21:41, Heikki Linnakangas wrote:
On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
Thanks for posting the patched HTML. In my opinion, all looks good
except that:
- I will add an extra String (a CSV) to AuthenticationSASL message for
channel binding names, so
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding
? Doesn't sound terribly friendly. A report of a certificate
mismatch is far more likely to lead people to realize there's a MITM.
So given what I said before, that won't happen. Indeed, SCRAM RFC
contains a specific error code for this: "channel-bindings-dont-match".
Álv
On 12/04/17 18:38, Robert Haas wrote:
On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
LOL. Do you really want a half-baked Java programmer writing a patch in
C for PostgreSQL? I once tried that and Magnus said my code was Java code
that ha
.
I'm working myself on Java's (pgjdbc) implementation, and I will
hopefully have a prototype by next week to try it.
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
equest packet) a list of auth protocols it thinks it is able to handle.
Per the SCRAM RFC, it is the server who advertises and the client
who picks.
Regards,
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
--
Sent via pgsql-hackers mailing list (p
's no way to negotiate, the client picks.
It could still be three-valued: on, off, only-channel-binding (or
however you want to call them). That will only change what mechanisms
the server will be advertising to clients.
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
rlier (to conform with the RFC).
Thoughts?
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rlier (to conform with the RFC).
Thoughts?
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/04/17 08:50, Heikki Linnakangas wrote:
On 04/10/2017 11:03 PM, Álvaro Hernández Tortosa wrote:
Channel binding needs to specify actually three things:
- The mechanism, which is indeed suffixed "-PLUS".
- The channel binding name, which is described here:
https://tools.iet
On 10/04/17 20:32, Andres Freund wrote:
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements
On 11/04/17 13:21, Heikki Linnakangas wrote:
On 04/11/2017 01:39 PM, Álvaro Hernández Tortosa wrote:
The fact that you null terminate them (fine with me) doesn't change
my reasoning. How do you separate multiple channel binding methods? And
do you realize that you will be repeating
On 11/04/17 12:23, Heikki Linnakangas wrote:
On 04/11/2017 11:55 AM, Álvaro Hernández Tortosa wrote:
On 11/04/17 08:50, Heikki Linnakangas wrote:
Oh, I see. According to the SCRAM RFC, "tls-unique" is used by
default. I don't see us implementing anything else any time soon.
On 11/04/17 15:03, Magnus Hagander wrote:
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa
<a...@8kdata.com <mailto:a...@8kdata.com>> wrote:
On 10/04/17 20:32, Andres Freund wrote:
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
On 11/04/17 15:18, Heikki Linnakangas wrote:
On 04/11/2017 04:09 PM, Álvaro Hernández Tortosa wrote:
But I will conserve my remaining courage (thanks Michael!) credits
for future threads ;) I have stated my opinion clearly, I will now go
back to the client library.
Once you're done
On 12/04/17 19:34, Heikki Linnakangas wrote:
On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
So I still see your proposal more awkward and less clear, mixing
things that are separate. But again, your choice :)
So, here's my more full-fledged proposal.
The first patch
On 13/04/17 13:24, Heikki Linnakangas wrote:
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
By looking at the them, and unless I'm missing something, I
don't see
how the extra information for the
On 13/04/17 04:54, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
By looking at the them, and unless I'm missing something, I don't see
how the extra information for the future implementation of channel binding
would be
On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
>
>> On 13/04/17 13:24, Heikki Linnakangas wrote:
>>
>>> Right, when we get channel binding, the server will list
>>> "SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms
name.
If there's a clear meaning about ignoring the user here, why not
settle on something like the "*"? It's not going to change the world
sending a few bytes less on initialization, but I guess it doesn't hurt
either...
Álvaro
--
Álvaro Hernández Tortosa
-
On 11/08/17 15:00, Michael Paquier wrote:
On Fri, Aug 11, 2017 at 9:31 PM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
On 11/08/17 13:18, Michael Paquier wrote:
On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
Relatedly, the SCRAM s
On 11/08/17 13:18, Michael Paquier wrote:
On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa
<a...@8kdata.com> wrote:
On 11/08/17 03:57, Peter Eisentraut wrote:
The SCRAM protocol documentation
(https://www.postgresql.org/docs/devel/static/sasl-authentication.html)
states
&qu
answer should also be coordinated
among the drivers.
Álvaro
--
Álvaro Hernández Tortosa
---
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 111 matches
Mail list logo
