On Thu, 17 Jan 2019 at 05:59, Laurenz Albe wrote:
> Tsunakawa, Takayuki wrote:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > > The problem here of course is that whoever invented
> target_session_attrs
> > > was unconcerned with following that precedent, so what we have is
> > > "target_sess
; >> 2) If there's no node on which pg_is_in_recovery() returns false, then
> >>we need to retry until we find it. To not retry forever, there
> >>should be a timeout counter parameter.
> >>
> >>
> > IIRC this is essentially
On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii wrote:
> > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
> >
> >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii
> wrote:
> >> >
> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> But pg_is_in_recovery() returns true even for a promo
On Thu, 17 Jan 2019 at 19:09, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Dave Cramer [mailto:p...@fastcrypt.com]
> > >> 2) If there's no node on which pg_is_in_recovery() returns
> false,
> > then
> > >>
On Thu, 17 Jan 2019 at 19:38, Tatsuo Ishii wrote:
> >> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> >> But pg_is_in_recovery() returns true even for a promoting
> >> standby. So
> >> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it
> >> >> >> >> finish
On Thu, 17 Jan 2019 at 19:56, Tatsuo Ishii wrote:
> >> > I'm curious; under what circumstances would the above occur?
> >>
> >> Former primary goes down and one of standbys is promoting but it is
> >> not promoted to new primary yet.
> >>
> >
> > seems like JDBC might have some work to do...Thank
On Tue, 11 Feb 2020 at 17:35, Tom Lane wrote:
> Vik Fearing writes:
> > There is a current discussion off-list about what should happen when a
> > COMMIT is issued for a transaction that cannot be committed for whatever
> > reason. PostgreSQL returns ROLLBACK as command tag but otherwise
> succ
as depending on how the transaction
failed we seem to do different things
In Tom's example we do issue a warning and say there is no transaction
running. I would guess we silently rolled back earlier.
In my example we don't issue the warning we just roll back.
I do agree with Tom that changing this behaviour at this point would make
things worse for more people than it would help so I am not advocating
throwing an error here.
I would however advocate for consistently doing the same thing with failed
transactions
Dave Cramer
www.postgres.rocks
On Fri, 14 Feb 2020 at 13:29, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 1:04 PM Dave Cramer
> wrote:
> > Thing is that con.commit() DOESN'T return a status code, nor does it
> throw an exception as we silently ROLLBACK here.
>
> Why not? There's nothing keepi
On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
> wrote:
> > Well now you are asking the driver to re-interpret the results in a
> different way than the server which is not what we tend to do.
> >
> > The server throws
On Fri, 14 Feb 2020 at 15:07, Tom Lane wrote:
> Dave Cramer writes:
> > On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> >> I'm not trying to deny that you might find some other server behavior
> >> more convenient. You might. And, to Vik's original p
On Fri, 14 Feb 2020 at 15:19, Alvaro Herrera
wrote:
> On 2020-Feb-14, Dave Cramer wrote:
>
> > I offered to make the behaviour in the JDBC driver dependent on a
> > configuration parameter
>
> Do you mean "if con.commit() results in a rollback, then an exception is
&
Hi,
Feel free to send out the email blast.
There are a number of other channels. postgres slack, postgres mailing
lists, @PostgreSQL Hackers , twitter
with Postgres tag
Cheers,
Dave Cramer
On Sat, 15 Feb 2020 at 19:44, 'Meetup Messages' via Meetup <
mee...@postgre
On Mon, 17 Feb 2020 at 13:02, Haumacher, Bernhard wrote:
> Am 14.02.2020 um 20:36 schrieb Robert Haas:
> > On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
> wrote:
> >> Well now you are asking the driver to re-interpret the results in a
> different way than the server whic
On Sun, 23 Feb 2020 at 00:41, Shay Rojansky wrote:
>
>
> On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
>>
>>> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
>>> wrote:
>>> > Well now you are asking the driver to re-interpret the results in a
>&g
rspective, is not that the driver behavior in the face of errors
> can't be made correct with the existing semantics, but that the driver
> would find it more convenient if PostgreSQL reported those errors in a
> somewhat different way. I think that's a fair criticism, but I don't
> think it's a sufficient reason to change the behavior.
>
I think the fact that this is a violation of the SQL SPEC lends
considerable credence to the argument for changing the behaviour.
Since this can lead to losing a transaction I think there is even more
reason to look at changing the behaviour.
Dave Cramer
www.postgres.rocks
On Mon, 24 Feb 2020 at 07:25, Robert Haas wrote:
> On Mon, Feb 24, 2020 at 7:29 AM Dave Cramer
> wrote:
> > Well the driver really isn't in the business of changing the semantics
> of the server.
>
> I mean, I just can't agree with that way of characterizing it. I
eded to be repaired. Seems to me it would be much easier if
everything failed.
> You may think that
> nobody is doing this sort of thing, but I think people are, and that
> they will come after us with pitchforks if we break it.
>
So the argument here is that we don't want to annoy some percentage of the
population by doing the right thing ?
Dave Cramer
www.postgres.rocks
//ignore this exception
}
conn.commit();
} catch ( SQLException ex ) {
ex.printStackTrace();
conn.rollback();
}
conn.close();
Dave Cramer
http://www.postgres.rocks
>
oint in that it's not nearly as bad as
> I thought you were suggesting (to treat commit as bad statement) but
> the transaction would still terminate. Still, this is very sensitive
> stuff, do you think most common connection poolers would continue to
> work after making this change?
>
Don't see why not. All that happens is that an error message is emitted by
the server on commit instead of silently rolling back
Dave Cramer
https://www.postgres.rocks
On Wed, 26 Feb 2020 at 13:46, Vik Fearing wrote:
> On 25/02/2020 12:11, Laurenz Albe wrote:
> > On Tue, 2020-02-25 at 13:25 +0530, Robert Haas wrote:
> >> On Tue, Feb 25, 2020 at 12:47 PM Vladimir Sitnikov
> >> wrote:
> >>> Noone suggested that "commit leaves the session in a transaction
> state
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
&g
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
&g
On Thu, 27 Feb 2020 at 07:44, Dave Cramer wrote:
>
>
>
> On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
>
>> On 26/02/2020 22:22, Tom Lane wrote:
>> > Dave Cramer writes:
>> >> OK, here is a patch that actually doesn't leave the transaction in
On Fri, 28 Feb 2020 at 18:34, Tom Lane wrote:
> Dave Cramer writes:
> > Rebased against head
>
> The cfbot's failing to apply this [1]. It looks like the reason is only
> that you included a catversion bump in what you submitted. Protocol is to
> *not* do that in s
On Thu, 27 Feb 2020 at 08:30, Dave Cramer wrote:
>
>
> On Thu, 27 Feb 2020 at 07:44, Dave Cramer
> wrote:
>
>>
>>
>>
>> On Wed, 26 Feb 2020 at 16:57, Vik Fearing
>> wrote:
>>
>>> On 26/02/2020 22:22, Tom Lane wrote:
>>> &g
On Fri, 6 Mar 2020 at 08:54, Petr Jelinek wrote:
> Hi Dave,
>
> On 29/02/2020 18:44, Dave Cramer wrote:
> >
> >
> > rebased and removed the catversion bump.
>
> Looked into this and it generally seems okay, but I do have one gripe here:
>
> > +
Dave Cramer
On Mon, 3 Jun 2019 at 20:54, David Fetter wrote:
> On Mon, Jun 03, 2019 at 10:49:54AM -0400, Dave Cramer wrote:
> > Is there a reason why pgoutput sends data in text format? Seems to
> > me that sending data in binary would provide a considerable
> > pe
Dave Cramer
On Tue, 4 Jun 2019 at 16:30, Andres Freund
wrote:
> Hi,
>
> On 2019-06-04 15:47:04 -0400, Dave Cramer wrote:
> > On Mon, 3 Jun 2019 at 20:54, David Fetter wrote:
> >
> > > On Mon, Jun 03, 2019 at 10:49:54AM -0400, Dave Cramer wrote:
> > >
On Tue, 4 Jun 2019 at 16:46, Andres Freund wrote:
> Hi,
>
> On 2019-06-04 16:39:32 -0400, Dave Cramer wrote:
> > On Tue, 4 Jun 2019 at 16:30, Andres Freund <
> andres.fre...@enterprisedb.com>
> > wrote:
> > > > There's also no reason that I am aware
On Tue, 4 Jun 2019 at 18:08, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 00:05:02 +0200, David Fetter wrote:
> > Would it make sense to work toward a binary format that's not
> > architecture-specific? I recall from COPY that our binary format is
> > not standardized across, for example, big- an
) so if you look for example at the
> write_tuple/read_tuple/decide_datum_transfer in
>
> https://github.com/2ndQuadrant/pglogical/blob/REL2_x_STABLE/pglogical_proto_native.c
> that can help you give some ideas on how to approach this.
>
Thanks for the tip!
Dave Cramer
>
>
>
On Wed, 5 Jun 2019 at 07:21, Dave Cramer wrote:
> Hi,
>
>
> On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
> wrote:
>
>> Hi,
>>
>> On 05/06/2019 00:08, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2019-06-05 00:05:02 +0200, David Fetter
Hi,
On Wed, 5 Jun 2019 at 12:01, Andres Freund wrote:
> Hi
>
> On June 5, 2019 8:51:10 AM PDT, Dave Cramer wrote:
> >On Wed, 5 Jun 2019 at 07:21, Dave Cramer wrote:
> >
> >> Hi,
> >>
> >>
> >> On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
Hi,
On Wed, 5 Jun 2019 at 18:50, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 18:47:57 -0400, Dave Cramer wrote:
> > So one of the things they would like added is to get not null information
> > in the schema record. This is so they can mark the field Optional in
>
This should have gone to hackers as well
-- Forwarded message -
From: Dave Cramer
Date: Sat, Jun 8, 2019, 6:41 PM
Subject: Re: Binary support for pgoutput plugin
To: Tomas Vondra
On Sat, Jun 8, 2019, 6:27 PM Tomas Vondra,
wrote:
> On Fri, Jun 07, 2019 at 06:01:12PM -0
On Sat, 8 Jun 2019 at 20:09, Andres Freund wrote:
> Hi,
>
> On 2019-06-08 19:41:34 -0400, Dave Cramer wrote:
> > So the reason we are discussing using pgoutput plugin is because it is
> part
> > of core and guaranteed to be in cloud providers solutions.
>
> IMO p
So back to binary output.
>From what I can tell the place to specify binary options would be in the
create publication and or in replication slots?
The challenge as I see it is that the subscriber would have to be able to
decode binary output.
Any thoughts on how to handle this? At the moment I'
data in
logicalrep_read_tuple but that would require moving a lot of the logic
currently in worker.c to proto.c. This seems minimally invasive.
and thanks Petr for the tip to use pglogical for ideas.
Thanks,
Dave Cramer
>
>
0001-First-pass-at-working-code-without-subscription-opti.patch
Descr
On Mon, 10 Jun 2019 at 07:49, Petr Jelinek
wrote:
> Hi,
>
> On 10/06/2019 13:27, Dave Cramer wrote:
> > So back to binary output.
> >
> > From what I can tell the place to specify binary options would be in the
> > create publication and or in replication slots?
Dave Cramer
On Fri, 14 Jun 2019 at 14:36, Tomas Vondra
wrote:
> On Wed, Jun 12, 2019 at 10:35:48AM -0400, Dave Cramer wrote:
> >On Mon, 10 Jun 2019 at 07:49, Petr Jelinek
> >wrote:
> >
> >> Hi,
> >>
> >> On 10/06/2019 13:27, Da
On Fri, 14 Jun 2019 at 15:42, Dave Cramer wrote:
>
> Dave Cramer
>
>
> On Fri, 14 Jun 2019 at 14:36, Tomas Vondra
> wrote:
>
>> On Wed, Jun 12, 2019 at 10:35:48AM -0400, Dave Cramer wrote:
>> >On Mon, 10 Jun 2019 at 07:49, Petr Jelinek > >
>> >
On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
wrote:
> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
> > wrote:
> >>
> >> On 2019-04-12 19:52, Robert Treat wrote:
> >> > It is clear to me that the docs are wrong, but I don't see any
On Thu, 27 Jun 2019 at 14:20, Tomas Vondra
wrote:
> On Thu, Jun 27, 2019 at 01:46:47PM -0400, Dave Cramer wrote:
> >On Thu, 27 Jun 2019 at 12:50, Tomas Vondra
> >wrote:
> >
> >> On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
> >> >On Sun
On Wed, 5 Jun 2019 at 18:50, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 18:47:57 -0400, Dave Cramer wrote:
> > So one of the things they would like added is to get not null information
> > in the schema record. This is so they can mark the field Optional in
> Java.
curs these
statements fail.
This seems like a rather innocuous change as the protocol is not changed,
rather the amount of information returned on startup is increased
marginally.
I've included the authors of the npgsql and the node drivers in the email
for their input.
Dave Cramer
On Mon, 8 Jul 2019 at 06:40, Thomas Munro wrote:
> On Thu, Mar 7, 2019 at 8:19 PM David Steele wrote:
> > On 2/16/19 10:38 PM, Dave Cramer wrote:
> > > Thanks for looking at this. FYI, I did not originally write this,
> rather
> > > the original author has not r
was a proposal to make reportable GUC's configurable here
https://www.postgresql.org/message-id/ca+tgmobsxsy0kfr_vdqqoxjxqafnesfxf_-darne+qhhqcw...@mail.gmail.com
I don't really care which one gets implemented, although I think the latter
makes more sense.
Dave Cramer
On Fri, 5 Jul 2019
more GUC REPORT variables, but I
see this as a much better way.
I'm willing to code the patch if we can get some buy in here ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On Wed, 10 Jul 2019 at 09:11, Robert Haas wrote:
> On Tue, Jul 9, 2019 at 2:32 PM Dave Cramer wrote:
> > So did this die from lack of interest?
> >
> > I have proposed in another thread adding more GUC REPORT variables, but
> I see this as a much better way.
> &g
On Wed, 10 Jul 2019 at 16:34, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote:
> >> I'm still a bit conflicted about what to do with search_path as I do
> believe this is potentially a security issue.
> >> It may be
On Thu, 11 Jul 2019 at 10:06, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer wrote:
> > See attached for an initial patch. If this is an acceptable way to go I
> will add tests and documentation
>
> And clean up the code? Doesn't look crazy on a quick
ustom_variable would need to consult
> > the list to see if a newly-defined variable should be marked GUC_REPORT.
>
This suggests creating a list in guc.c instead. I'm unclear as to the
visibility of variables in there
How do I make this list visible only to the session ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
>
>
On Wed, 10 Jul 2019 at 16:22, Robert Haas wrote:
> On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote:
> > I'm still a bit conflicted about what to do with search_path as I do
> believe this is potentially a security issue.
> > It may be that we always want to report that
On Thu, 11 Jul 2019 at 15:07, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 2:29 PM Dave Cramer wrote:
> > So if I understand this correctly if user bob has altered his search
> path and there is a security-definer function called owned by him then
> > the search path will
While trying to figure out this code I found
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/logical/logical.c;h=61588d626f608006196c769ad9807f1d3ac592e9;hb=HEAD#l913
What function should it be referring to ?
Thanks,
Dave Cramer
rporate-friendly like other software under Apache
> License.
>
> Certainly there is history of people using PG code for non-PostgreSQL or
at least commercial derivative work. Greenplum for example.
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
e were to be able to change the file name
and create a new file based on some form of template ?
Am I missing something ?
Dave Cramer
On 6 July 2018 at 14:11, Andres Freund wrote:
> Hi,
>
> On 2018-07-06 13:49:37 -0400, Dave Cramer wrote:
> > There is some undocumented (nothing in the docs) code that allows for
> > closing reopening the output file for pg_recvlogical.
> >
> > Since this doesn
>
>
> On 6 July 2018 at 14:11, Andres Freund wrote:
>
>> Hi,
>>
>> On 2018-07-06 13:49:37 -0400, Dave Cramer wrote:
>> > There is some undocumented (nothing in the docs) code that allows for
>> > closing reopening the output file for pg_recvlogical.
en the proliferation of cloud based
implementations I can see this being a useful feature.
Regards,
Dave Cramer
d the patches and attached them for consideration.
JDBC tests here
https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/test/java/org/postgresql/replication/LogicalReplicationTest.java
all pass
Regards,
Dave Cramer
0004-Add-test-for-pg_recvlogical-to-stop-replication.patch
Description: Binary
Since nothing else can be done we should throw an error early.
Dave Cramer
On 26 July 2018 at 16:49, Andres Freund wrote:
> Hi,
>
> On 2018-07-26 16:40:18 -0400, Dave Cramer wrote:
> > Since nothing else can be done we should throw an error early.
>
> I can't immediately think of a reason not to do that, but I personally
> don't care
will
return an error instead and abort the copy connection.
Dave Cramer
0002-remove-space.patch
Description: Binary data
0001-Ensure-that-pg_create_physical_replication_slot-erro.patch
Description: Binary data
On 31 July 2018 at 14:58, Andres Freund wrote:
> Hi,
>
> On 2018-07-31 14:51:12 -0400, Dave Cramer wrote:
> > This patch does 2 things
> >
> > 1) Ensure that when the slot is created
> > with pg_create_physical_replication_slot if the output plugin does not
>
On 1 August 2018 at 10:13, Petr Jelinek
wrote:
> Hi,
>
> On 31/07/18 20:58, Andres Freund wrote>
> >> diff --git a/src/backend/replication/logical/logical.c
> b/src/backend/replication/logical/logical.c
> >> index 3cd4eef..9f883b9 100644
> >> --- a/src/backend/replication/logical/logical.c
> >> +
certainly
> not a newcomer.)
>
I am looking for this in the commitfest and can't find it. However there is
an old commitfest entry
https://commitfest.postgresql.org/13/1024/
Do you have the link for the new one ?
Dave Cramer
www.postgres.rocks
>
>
>
Dave Cramer
www.postgres.rocks
On Mon, 31 Aug 2020 at 11:46, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Hi,
>
> It seems like this patch is nearly finished. I fixed all the remaining
> issues. I'm also asking
> a confirmation of the test scenarios y
On Mon, 21 Sep 2020 at 09:21, Matthieu Garrigues <
matthieu.garrig...@gmail.com> wrote:
> Matthieu Garrigues
>
> On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer
> wrote:
> >>
> > There was a comment upthread a while back that people should look at the
> comments
On Mon, 28 Sep 2020 at 20:08, Andy Fan wrote:
>
>
> On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> >100% compatible with the MySQL
>>
>> It is hardly a justification for a feature or for a change request.
>>
>> Vladimir
>>
>
I would have to agree. T
On Tue, 29 Sep 2020 at 14:33, Andrew Dunstan
wrote:
>
> On 9/29/20 10:26 AM, Peter Eisentraut wrote:
> > On 2020-09-28 15:46, Vladimir Sitnikov wrote:
> >> The concerns to avoid "Clob maps to text" could be:
> >> a) Once the behavior is implemented, it is hard to change. That is
> >> applications
On Fri, 9 Oct 2020 at 13:33, Andrew Dunstan wrote:
>
> On 10/8/20 3:46 AM, Peter Eisentraut wrote:
> > I want to progress work on stored procedures returning multiple result
> > sets. Examples of how this could work on the SQL side have previously
> > been shown [0]. We also have ongoing work t
Hi,
On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> Hi,
>
> On 2020-10-08 09:46:38 +0200, Peter Eisentraut wrote:
> > New would be that the server would now also respond with a new message,
> say,
> >
> > S: DynamicResultInfo
>
> > Now, if the client has seen DynamicResultInfo earlier, it s
On Fri, 9 Oct 2020 at 14:59, Andres Freund wrote:
> Hi,
>
> On 2020-10-09 14:49:11 -0400, Dave Cramer wrote:
> > On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> > > > (I suspect what would be more useful in practice is to designate
> > > > output
On Tue, 20 Oct 2020 at 05:57, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-09 21:02, Dave Cramer wrote:
> > For the most part we know exactly which types we want in binary for 99%
> > of queries.
> >
> > The hard part around this
On Tue, 20 Oct 2020 at 20:09, Andres Freund wrote:
> Hi,
>
> On 2020-10-20 18:55:41 -0500, Jack Christensen wrote:
> > Upthread someone posted a page pgjdbc detailing desired changes to the
> > backend protocol (
> >
> https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_featur
dra
>
> Congratulations to all!
>
> regards, tom lane
>
> +7
Congratulations to all!
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
x27;t looked at the patch but if we get to the point of negotiating
compression please let me know.
Thanks,
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
l it is true that HEAD is cleaner with its simplicity.
>
>
I'm unclear what this has to do with JDBC ? JDBC doesn't use OpenSSL
Alvaro ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
We are having a discussion on the jdbc project about dealing with 24:00:00.
https://github.com/pgjdbc/pgjdbc/pull/992#issuecomment-354507612
Dave Cramer
On Thu, 16 Aug 2018 at 13:54, Shay Rojansky wrote:
> Peter,
>
> I think this is all coming from Microsoft. The JDBC driver API was
>> modeled after the ODBC API, and the ODBC specification also contains the
>> {call} escape. Microsoft SQL Server is also the only SQL implementation
>> to handle
Dave Cramer
On Thu, 16 Aug 2018 at 18:27, Jonathan S. Katz <
jonathan.k...@excoventures.com> wrote:
>
> On Aug 16, 2018, at 1:05 AM, Jonathan S. Katz <
> jonathan.k...@excoventures.com> wrote:
>
>
> On Aug 15, 2018, at 9:15 PM, Michael Paquier wrote:
>
>
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On Fri, 17 Aug 2018 at 18:30, Alvaro Herrera
wrote:
> On 2018-Aug-17, Jonathan S. Katz wrote:
>
> > Hi,
> >
> > I Initially pointed out here[1] that running REFRESH MATERIALIZED VIEW
> as a
> > non-su
On Fri, 17 Aug 2018 at 19:35, Alvaro Herrera
wrote:
> On 2018-Aug-17, Dave Cramer wrote:
>
> > The only place this is used is in aclcheck_error
> > case OBJECT_MATVIEW:
> > msg = gettext_noop("permission denied for materialized view %s");
> > break;
&g
On Sat, 18 Aug 2018 at 17:30, Jonathan S. Katz wrote:
>
> On Aug 18, 2018, at 5:26 PM, David G. Johnston
> wrote:
>
> On Saturday, August 18, 2018, Jonathan S. Katz
> wrote:
>>
>> It’s cosmetic, but it’s a cosmetic bug: it incorrectly tells the user
>> that they
>> must be the owner of the “rel
On Sat, 18 Aug 2018 at 17:48, Tom Lane wrote:
> Dave Cramer writes:
> > This is a simple fix why push back ?
>
> What was being pushed back on, I think, was the claim that this needed to
> be back-patched. I'd be inclined not to, since (a) the message is not
> wrong,
f
this work it would be a shame not to make it easy to use.
I also agree with David that driver writers made the best out of the
situation with functions and we are now asking for the server to dual
purpose the call command.
Is there a technical reason why this is not possible ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
>
>
bridge at this
> point. Nevertheless, I predict that this is going to be an ongoing
> source of pain for a long time to come.
>
> Undoubtedly.. surely the opportunity to do something about this has not
passed as this has not been
officially released ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
in src/test/ssl the README suggest that the Makefile can be used to
recreate the ssl directory, however there are no rules to create
*_ca.crt|key. Am I missing something ?
Dave Cramer
On Sun, 16 Sep 2018 at 14:41, Heikki Linnakangas wrote:
> On 14/09/18 18:49, Dave Cramer wrote:
> > in src/test/ssl the README suggest that the Makefile can be used to
> > recreate the ssl directory, however there are no rules to create
> > *_ca.crt|key. Am I missing somet
transaction.
Is there anything else I am missing ? Does DDL get applied after the
transaction ends ?
I do find this somewhat surprising as Postgres typically requires a BEGIN
statement to start a transaction block.
Thanks
Dave Cramer
On Sun, 29 Sept 2024 at 06:31, Dave Cramer
wrote:
>
> On Sat, 28 Sept 2024 at 20:03, Thomas Munro
> wrote:
>
>> On Tue, Feb 13, 2024 at 10:01 AM Dave Cramer
>> wrote:
>> > > postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
>
On Tue, 13 Feb 2024 at 16:28, Dave Cramer wrote:
>
>
>
> On Tue, 13 Feb 2024 at 12:52, Andres Freund wrote:
>
>> Hi,
>>
>> On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
>> > > I think I might have been on to something - if my human emulation of a
On Tue, 24 Sept 2024 at 14:31, Dave Cramer
wrote:
>
>
> On Tue, 13 Feb 2024 at 16:28, Dave Cramer
> wrote:
>
>>
>>
>>
>> On Tue, 13 Feb 2024 at 12:52, Andres Freund wrote:
>>
>>> Hi,
>>>
>>> On 2024-02-13 12:49:33 -0500, D
On Sat, 28 Sept 2024 at 20:03, Thomas Munro wrote:
> On Tue, Feb 13, 2024 at 10:01 AM Dave Cramer
> wrote:
> > > postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
> > postgres.exe!resize(dshash_table * hash_table, unsigned __int64
> n
Greetings,
Previously we have replaced the use of literal characters with pqMsg*. Not
sure how this one escaped detection.
Patch attached.
Dave Cramer
0001-use-pqMsg_Query-instead-of-Q.patch
Description: Binary data
On Thu, 10 Apr 2025 at 09:54, Fujii Masao
wrote:
>
>
> On 2025/04/10 18:52, Dave Cramer wrote:
> > Greetings,
> >
> > The current docs say that if a client asks for a protocol that the
> backend doesn't support, it will return the newest minor version.
> h
On Thu, 10 Apr 2025 at 11:17, Fujii Masao
wrote:
>
>
> On 2025/04/10 23:40, Dave Cramer wrote:
> >
> > On Thu, 10 Apr 2025 at 09:54, Fujii Masao <mailto:masao.fu...@oss.nttdata.com>> wrote:
> >
> >
> >
> > On 202
;t what it returns. It actually returns the entire newest
protocol that it supports. Attached is a patch to fix the docs.
Dave Cramer
protocol.patch
Description: Binary data
301 - 400 of 418 matches
Mail list logo
