ed at least twice already that this kind of solution is bad,
I don't know of any change that would invalidate the reasons for
deciding that way so I don't see why they would suddenly become
acceptable...
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Develo
from connection configuration, it can get the it from the
output plugin as part of wire protocol, it can generate it based on some
internal logic, etc.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
sure if anyone else wants to
review. Still needs docs.
I'd like to see this one when it's updated since I lost track a little
about how the changes looks like exactly.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
t of INSERT (at least I haven't seen any
proposal that I would consider sane from the user point of view).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 09/09/14 19:05, Petr Jelinek wrote:
Hi,
I worked bit on this patch to make it closer to committable state.
There are several bugs fixed, including ones mentioned by Jamie (writing
WAL during recovery).
Also support for pg_resetxlog/pg_upgrade has been implemented by Andres.
I added simple
t I think the
patch is good enough for the review now, so I am adding it to October
commitfest.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/access/Makefile b/src/backend/access/Makefile
index
ccept
the snapshot as input parameter? I am not sure how much I like pg_dump
creating the slot. I am aware that you need to have the replication
connection open but that's IMHO just matter of scripting it together.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL D
, you still get "asynchronous transactions").
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ssion test added for this feature.
Did some manual testing, seems to work as advertised.
There are no docs at the moment which is the only show-stopper that I
can see so far.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Serv
/functioncmds.c
create untrusted-language functions
I often needed more granularity there (plproxy).
commands/functioncmds.c
execute DO blocks with untrusted languages
I am not sure if this is significantly different from untrusted-language
functions.
--
Petr Jelinek
On 16/10/14 13:44, Stephen Frost wrote:
* Petr Jelinek (p...@2ndquadrant.com) wrote:
On 15/10/14 07:22, Stephen Frost wrote:
First though, the new privileges, about which the bikeshedding can
begin, short-and-sweet format:
BACKUP:
pg_start_backup()
pg_stop_backup
On 16/10/14 13:29, Pavel Stehule wrote:
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek
Great, looks good to me, marking as ready for committer.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hac
which DBA has access to. DBA can turn off logging (and the plugin)
altogether or change logging config but we'd get the shutdown log when
that happens so 10.2.2 and 10.2.6 will be fulfilled in that case I think.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL
t too much, but I don't have better suggestion, if we
went with one of these, I would prefer taking the route of renaming the
dsm_keep_mapping to dsm_unregister_mapping.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
ded for. I don't see why this should
be required to work cross version really.
Loading of the modules by bgworker is probably bigger issue than just
GUCs, and I think it's out of scope for the current patch(set).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Develo
you want to auto-magically detect what value is behind the EXCLUDED
based on how/where it's used in the UPDATE? That seems like quite a bad
idea.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
rs > 1 && AH->remoteVersion >= 90200 &&
!dopt->no_synchronized_snapshots)
AH->sync_snapshot_id = get_synchronized_snapshot(AH);
And remove the else if for the if (dumpsnapshot) part.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Devel
than perfect error message, but I really don't think it's worth the
trouble to have special handling for it as the message coming from the
server is clear enough IMHO.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
discussion about
design and particular implementation choices, there is fair amount of
TODOs and FIXMEs. I'd like to look at it too but I doubt that I'll have
time to do in depth review in this CF.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Devel
ay as well, because either
nobody's using this yet, in which case back-patching it won't break
anything, or somebody is, in which case we'll cause less pain by
breaking it before release than a year on. But I don't care that much
either way, so I'll defer if other
by
design since otherwise we would have to write checkpoint on shutdown and
that would mean the instance can't be used as hot standby anymore and I
consider that an important feature to have.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
e.
The feature's overhead might be small, but it is most certainly not zero,
and people shouldn't be paying for it unless they need it.
Agreed, that's why it stayed 'off' in my version too.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL D
Hi,
Attached is the v2 of the patch with the review comments addressed (see
below).
On 29/10/14 21:08, Petr Jelinek wrote:
On 29/10/14 20:27, Asif Naeem wrote:
1. It seems that following log message need to be more descriptive about
reason for shutdown i.e.
+ if
Hi,
On 28/10/14 13:25, Simon Riggs wrote:
On 13 October 2014 10:05, Petr Jelinek wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.
I've reviewed this and it looks good to me.
d contrib/test_committs. So I'd just rip it off. On
Those tests are different though, one tests that the default (off) works
as expected the contrib one tests that the feature when turned on works
as expected. Since we can only set config values for contrib tests I
don't
On 01/11/14 12:19, Petr Jelinek wrote:
Hi,
thanks for review.
On 01/11/14 05:45, Michael Paquier wrote:
Now here are a couple of comments at code level, this code seems not
enough baked for a commit:
1) The following renaming should be done:
- pg_get_transaction_committime to
r patch that is discussed in separate thread.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
btransaction problem and refer to some
transaction metadata table.
Well, Michael has point that the extradata is pretty much useless
currently, perhaps it would help to add the interface to set extradata?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Developme
On 03/11/14 22:26, Peter Eisentraut wrote:
On 11/1/14 8:04 AM, Petr Jelinek wrote:
On second thought, maybe those should be pg_get_transaction_committs,
pg_get_transaction_committs_data, etc.
Please don't name anything "committs". That looks like a misspelling of
something.
T
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really
On 04/11/14 09:05, Andres Freund wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But
committsxlog.c or similar. The other rmgr do so, so let's be
consistent.
Most actually don't AFAICS.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 04/11/14 09:25, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund mailto:and...@2ndquadrant.com>> wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
> Well, Michael has point that the extradata is pretty much useless
currently,
> perhaps it w
On 04/11/14 22:20, Peter Eisentraut wrote:
On 11/3/14 5:17 PM, Petr Jelinek wrote:
Please don't name anything "committs". That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_timestamp()
If you want to reduce the length, lose the
On 05/11/14 13:45, Heikki Linnakangas wrote:
On 11/04/2014 11:01 PM, Petr Jelinek wrote:
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Only the alloc and reloptions methods are required (and implemented by
the local AM).
The caching, xlog writing
On 05/11/14 18:32, Heikki Linnakangas wrote:
On 11/05/2014 05:07 PM, Petr Jelinek wrote:
On 05/11/14 13:45, Heikki Linnakangas wrote:
In fact, if the seqam manages the current value outside the database
(e.g. a "remote" seqam that gets the value from another server),
nextval() neve
On 06/11/14 11:22, Craig Ringer wrote:
On 11/05/2014 05:01 AM, Petr Jelinek wrote:
I guess I could port BDR sequences to this if it would help (once we
have bit more solid agreement that the proposed API at least
theoretically seems ok so that I don't have to rewrite it 10 times if a
t we split the
extradata in for bytes for the namespace and four for the actual
data. That's roughly how it works for advisory locks already.
I am not sure how would this solve problem of 2 extensions using the
extradata given that there can be only 1 record per txid anyway.
--
Petr J
optional and enabled us to take step
forward with replication and had some side uses besides replication just
like commit timestamps do.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hacke
On 08/11/14 00:45, Robert Haas wrote:
On Nov 5, 2014, at 5:43 PM, Petr Jelinek wrote:
I don't see how to make that work with ALTER SEQUENCE USING to be honest and I do care
quite a lot about that use-case (I think the ability to convert the "local"
sequences to 3rd party o
u
want to call it there, as that's the one I personally have biggest
use-case for.
So this would be ~24bytes per txid already, hmm I wonder if we can pull
some tricks to lower that a bit.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
On 08/11/14 00:57, Petr Jelinek wrote:
On 08/11/14 00:45, Robert Haas wrote:
On Nov 5, 2014, at 5:43 PM, Petr Jelinek wrote:
I don't see how to make that work with ALTER SEQUENCE USING to be
honest and I do care quite a lot about that use-case (I think the
ability to convert the &
On 08/11/14 03:05, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek wrote:
but we can't have everything there
as there are space constraints, and LSN is another 8 bytes and I still want
to have some bytes for storing the "origin" or whatever you want to call it
t
On 08/11/14 03:10, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM then supposed to know
instead of column/type one
- or record dependency between the column and extension for ALTER
TABLE ADD COLUMN and ALTER TABLE ALTER COLUMN TYPE statements
Thoughts?
Oh and btw looking at the code I think there is same issue with
column/collation dependencies.
--
Petr Jelinek
I somehow missed it when I looked manually
(I didn't use pg_describe_object).
But the problem with the extension persists, I will try to dig more to
find what is the real cause.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
able there, but that's not
exactly super pretty solution.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On 09/11/14 20:47, Heikki Linnakangas wrote:
On 11/08/2014 01:57 AM, Petr Jelinek wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM then supposed to know where
On 09/11/14 23:36, Petr Jelinek wrote:
On 09/11/14 23:04, Tom Lane wrote:
I suspect this is actually a bug in the dependency search logic in DROP.
Don't have the energy to chase it right now though.
Yes that's where I started searching also and yes it is. The actual
situation i
o the info about it does not have either?
But anyway this patch is targeting extensions not DBAs - you could write
extension that will provide that feature on top of this patch (although
given what I wrote above I don't see how it's useful).
--
Petr Jelinek http:/
On 09/11/14 17:57, Steve Singer wrote:
On 11/07/2014 07:07 PM, Petr Jelinek wrote:
The list of what is useful might be long, but we can't have everything
there as there are space constraints, and LSN is another 8 bytes and I
still want to have some bytes for storing the "origin"
ability to put an event trigger function in place that makes
DDL requests fail.
That's more useful than you'd think; if, by default, we make them fail,
and with an error messages such as
"DDL request failed as it was not submitted using slonik DDL TOOL"
You can do that al
ked with flags indicating that dropping is allowed. Accordingly, the
attached patch should do it.
Yup, this patch seems to be much better and safer fix.
I can confirm that it works fine with both the test-case and my original
upgrade script. Thanks!
--
Petr Jelinek
On 10/11/14 14:53, Robert Haas wrote:
On Mon, Nov 10, 2014 at 8:39 AM, Petr Jelinek wrote:
I did the calculation above wrong btw, it's actually 20 bytes not 24 bytes
per record, I am inclined to just say we can live with that.
If you do it as 20 bytes, you'll have to do some work
On 13/11/14 07:04, Michael Paquier wrote:
On Wed, Nov 12, 2014 at 10:06 PM, Petr Jelinek wrote:
Brief list of changes:
- the commit timestamp record now stores timestamp, lsn and nodeid
Now that not only the commit timestamp is stored, calling that "commit
timestamp", &qu
s *not*
enable us to do something that would be impossible otherwise.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
an be more fun for someone, who
intensive use this pattern.
Personally, I see this as natural extension of the conditional block
control which we already have for loops with CONTINUE WHEN and EXIT
WHEN. This basically extends it to any block and it seems quite natural
to have it fo
On 18/11/14 12:57, Simon Riggs wrote:
On 31 October 2014 15:18, Petr Jelinek wrote:
Attached is the v2 of the patch with the review comments addressed (see
below).
...
Done, there is now action_at_recovery_target which can be set to either
pause, continue or shutdown, defaulting to pause
be better served by putting that info into
actual table instead of SLRU - as people want to use it as filter in
WHERE clause, somebody mentioned exporting to different db, etc.
Maybe we need better explanation of the LSN use-case(s) to understand
why it should be stored here and
On 19/11/14 12:20, Simon Riggs wrote:
On 19 November 2014 02:12, Petr Jelinek wrote:
Maybe we need better explanation of the LSN use-case(s) to understand why it
should be stored here and why the other solutions are significantly worse.
We should apply the same standard that has been
On 19/11/14 14:13, Simon Riggs wrote:
On 18 November 2014 22:05, Petr Jelinek wrote:
OK, promote works for me as well, I attached patch that changes continue to
promote so you don't have to find and replace everything yourself. The
changed doc wording probably needs to be checked.
difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sen
inish renaming the recovery.conf to recovery.done,
bumping timeline etc, and we don't want that since that prevents
resuming recovery in the future.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-h
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek wrote:
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code?
Try thi
ction commit
record and then if committs WAL record is found it's used to overwrite
the commit timestamp/nodeid for given xid.
Also, there is exactly one record in SLRU for each xid so there is no
point in making the SQL interfaces return multiple results.
--
Petr Jelinek
On 21/11/14 00:17, Petr Jelinek wrote:
On 19/11/14 17:30, Steve Singer wrote:
On 11/19/2014 08:22 AM, Alvaro Herrera wrote:
I think we're overblowing the pg_upgrade issue. Surely we don't need to
preserve commit_ts data when upgrading across major versions; and
pg_upgrade is
ory there is needed
(src/test//commit_ts). Not sure what the could
be, maybe something like "standalone" as those tests get their own pg
instance?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sen
for xids that are out of range by returning -infinity and
then changing that to NULL in sql interface, but no idea how to do that
for aborted transactions.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent v
On 25/11/14 16:30, Alvaro Herrera wrote:
Petr Jelinek wrote:
On 25/11/14 16:23, Alvaro Herrera wrote:
Robert Haas wrote:
Maybe 0 should get translated to a NULL return, instead of a bogus timestamp.
That's one idea --- surely no transaction is going to commit at 00:00:00
on 2000-
refer to the same xid and can
subtract to give us an exact replication lag.
Won't the pg_last_committed_xact() on slave + pg_xact_commit_timestamp()
on master with the xid returned by slave accomplish the same thing?
--
Petr Jelinek http://www.2ndQuadrant.com/
Postg
and we aren't in HS then they
should get Shutdown, which is closest action.
If the user doesn't request anything at all then we can default to
Promote, just like we do now.
Yes, this is what I was trying to suggest. +1 to do that.
Implemented.
Patch committed.
Thanks!
--
Petr
have special boolean option for it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
usually what you want is BgWorkerStart_RecoveryFinished).
Then you'll have the shmem hook called before the bgworker is actually
started.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-ha
ook this over I would appreciate it.
While this seems good, I'd code it slightly differently. I didn't like
the addition of new bool when it's not really needed. This brings the
question if we actually need the BootStrapCommitTs and StartupCommitTs
functions which really don't
her than the server itself, and in particular
pg_dump, vastly increases the failure surface area.
Well, it's better than trying to write completely new catalogs dump tool
for this. As Craig said, it would be best if pg_dump functionality was
moved to functions in a backend, but that's
patch (for example the validation functions).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2015-12-12 23:17, Alexander Korotkov wrote:
On Sat, Dec 12, 2015 at 9:21 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote:
On 2015-12-09 15:09, Alexander Korotkov wrote:
​Patch was rebased against current master.
Any notes about current version of patch?
k well in most cases. In this scenario
your method would be used for checking that sequence is close to going
over buffer and firing the periodic send sooner than it would be if it
was purely time based.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 2015-12-15 13:51, Andres Freund wrote:
On 2015-12-15 13:46:29 +0100, Petr Jelinek wrote:
I don't think that approach alone is good enough. It might be ok for
selective replication where the replication is driven by tables anyway, but
in general and especially for failover it'
n, one apply process is started per
subscription, connects to the walsender on the other side and applies
the changes received from there
[1] https://commitfest.postgresql.org/8/418/
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
Hi,
I noticed that the filter callback is documented as
LogicalDecodeChangeCB in the logical decoding docs. Here is one-line
patch to fix it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
logical-decoding-fi
can be used to create tables for which all inserts
only go to the WAL so they can behave like queue without having to store
the data in the table itself (kind of the opposite of unlogged tables)
Initial implementation of this proposal is attached.
--
Petr Jelinek http://www.
think the amroutine in RelationData should be
named rd_amroutine for consistency.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
91fa7b4719ac583420d9143132ba4ccddefbc5b2 breaks linking and fix
is few commits later.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2016-01-02 10:46, Andres Freund wrote:
Hi Petr,
On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote:
so the commit which triggers this issue is
387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to give
heads up early since multiple people are looking at this). Note that the
On 2016-01-02 12:05, Amit Kapila wrote:
On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund mailto:and...@anarazel.de>> wrote:
Hi Petr,
On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote:
> so the commit which triggers this issue is
> 387da18874afa17156ee3af63766f17efb53c4b
away */
return b;
already does the trick?
Yes it does indeed fix it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
ling with any regards to what's happening around
(wal order is still preserved though).
Will make this clearer in the docs.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
r helping you
> > or me. It's for helping the Rails users.
>
> I am not targeting anything. All I am saying is that if some framework
(not the
> framework's users!) wants to build something like that today its not all
that
> complicated.
I would prefer to be able to de
>
+1
And for the minority who wants to check themselves (like me) in their tooling
this is also usable solution.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t; Event triggers get called *during* the ALTER TABLE. So if were not careful
> they see something thats not easy to handle.
>
I thought the point of this was to call the trigger *before* anything
happens.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Andres Freund
> Sent: 06 December 2012 20:44
> To: Petr Jelinek
> Cc: 'Simon Riggs'; 'Robert Haas'; 'Dimitri Fontaine'
s
> up for 9.3!
>
+1
And the sooner we do it before release, the more time will those external
tools have to adjust.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Pavel Stehule
> Sent: 28 November 2012 11:07
> To: Selena Deckelmann
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> Hel
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: 26 January 2013 18:16
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> "Petr Jelinek" writes:
&g
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 26 January 2013 20:12
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> I wrote:
> > [ pokes around... ] Hm, it appears that that does work on Linux,
> > because for some reason we're specifying R
some of the points you raise are valid, but in my (minority) opinion
> overloading creates more problems than it solves. You're not going to
> convince me that get() is *ever* a good name for a function - you might as
> well call it thing() or foo() for all the useful information tha
32bit and 64bit targets and it
worked fine too (except for missing stdbool.h in msvc which is no big deal).
The coding style compared to cJSON (or other libs I've seen) seems
closer to the style of PostgreSQL, it would however still require
pgindent run and maybe some minor adjustments.
n
into core, so that you are not reinventing too many wheels. I can see
how your own code is good thing for general library which this can (and
I am sure will be) used as, but for the datatype itself, it might be
better idea to use what's already there, unless it's somehow
inco
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
On Tue, Apr 6, 2010 at 1:00 AM, Petr Jelinek wrote:
Not really sure about this myself, but keep in mind that NULL has special
meaning in SQL.
To me, the most logical approach is to do the obvious thing: make
JSON's 'null'
701 - 800 of 1163 matches
Mail list logo
