On 16/01/2019 22:40, Erik Rijkers wrote:
> I couldn't compile v7-0001 and I am testing with the older v6-0001 (of
> which I still had an instance).
>
> So the problem below may have been fixed already.
>
> If you add a generated column to a file_fdw foreign table, it works OK
> wih VIRTUAL
On Thu, 17 Jan 2019 at 03:42, David Rowley wrote:
> 35. The evaluation order of this macro is wrong.
>
> #define ITEM_SIZE(ndims) \
> (ndims * (sizeof(uint16) + sizeof(bool)) + 2 * sizeof(double))
>
> You'd probably want ITEM_SIZE(10) to return 170, but:
>
> select (10 * (2 + 1) + 2 * 8);
>
On Thu, Jan 17, 2019 at 1:33 AM Robert Haas wrote:
>
> On Wed, Jan 16, 2019 at 3:30 AM Masahiko Sawada wrote:
> > As the above comment says, it's possible that the state of an
> > INSERT_IN_PROGRESS tuple could be changed to 'dead' after
> > heap_page_prune(). Since such tuple is not truncated
>> On 2018-Dec-03, Tatsuo Ishii wrote:
>>
>>> To:
>>> ---
>>> -M querymode
>>> --protocol=querymode
>>>
>>> Protocol to use for submitting queries to the server:
>>>
>>> simple: use simple query protocol.
>>>
>>>
On Thu, Jan 17, 2019 at 02:44:25PM +0900, Etsuro Fujita wrote:
> Pushed. I left that argument alone. I think we can change it later, if
> necessary :).
Sure, that's fine as well. Thanks for committing the patch.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jan 08, 2019 at 09:09:56AM +0100, Christoph Berg wrote:
> Re: Andres Freund 2019-01-08
> <20190108011837.n4mx7dadvojv2...@alap3.anarazel.de>
>>> Here's another revision that doesn't add an extra CXXOPT variable but
>>> just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
(2019/01/16 20:30), Etsuro Fujita wrote:
(2019/01/16 15:54), Michael Paquier wrote:
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
If there are no objections, I'll commit that version of the patch.
I think that you could use PgFdwModifyState for the second argument of
> "Donald" == Donald Dong writes:
Donald> Hi,
Donald> I'm trying to reproduce the results by calling float4in in my
Donald> test code. But I have some difficulties linking the code:
Donald> testfloat4.c:(.text+0x34): undefined reference to `float4in'
Donald> testfloat4.c:(.text+0x3c):
On Wed, Jan 16, 2019 at 05:56:15PM +0100, Andreas Karlsson wrote:
> On 1/16/19 9:27 AM, Michael Paquier wrote:
>> Does somebody mind if I jump into the ship after so long? I was the
>> original author of the monster after all...
>
> Fine by me. Peter?
Okay, I have begun digging into the patch,
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth
> wrote:
>
> Andres> strtod()'s job ought to computationally be significantly easier
> Andres> than the other way round, no? And if there's buggy strtod()
> Andres> implementations out there, why would they be guaranteed to do
> Andres> the correct
Although we've got a few NetBSD and OpenBSD buildfarm critters,
none of them are doing --enable-tap-tests. If they were, we'd
have noticed the pgbench regression tests falling over:
not ok 3 - pgbench option error: bad option stderr /(?^:(unrecognized|illegal)
option)/
# Failed test 'pgbench
On 2019/01/04 9:53, David Rowley wrote:
> Without PREPAREd statements, if the planner itself was unable to prune
> the partitions it would already have obtained the lock during
> planning, so AcquireExecutorLocks(), in this case, would bump into the
> local lock hash table entry and forego trying
On Thu, 17 Jan 2019 at 01:56, David Rowley wrote:
> At this stage I'm trying to get to know the patch. I read a lot of
> discussing between you and Dean ironing out how the stats should be
> used to form selectivities. At the time I'd not read the patch yet,
> so most of it went over my head.
>
On Wed, Jan 16, 2019 at 10:10 PM John Naylor
wrote:
>
> On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila wrote:
> >
> > On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> > wrote:
> > 1.
> > Commit message:
> > > Any pages with wasted free space become visible at next relation
> > > extension, so we
On Wed, Jan 16, 2019 at 11:25 PM Tom Lane wrote:
>
> John Naylor writes:
> > It just occured to me that the style FSM_LOCAL_MAP_EXISTS seems more
> > common for macros that refer to constants, and FSMLocalMapExists for
> > expressions, but I've only seen a small amount of the code base. Do we
>
> "Tom" == Tom Lane writes:
>> I'll be looking into this in detail later, but right now, cam anyone
>> think of any reason why parseCheckAggregates couldn't be moved to
>> after assign_query_collations?
Tom> I never particularly liked assign_query_collations, as a matter of
Tom>
> "Tom" == Tom Lane writes:
>> (FWIW, I'm running the patch on gaur's host, just to confirm it
>> does what you expect. Should have an answer in an hour or so ...)
Tom> It does --- it compiles cleanly, and the float4 output matches
Tom> float4-misrounded-input.out.
Well I'm glad
On Thu, 17 Jan 2019 at 14:19, Tomas Vondra wrote:
> > 12. Should we be referencing the source from the docs?
> >
> > See mcv_clauselist_selectivity
> > in src/backend/statistics/mcv.c for details.
> >
> > hmm. I see it's not the first going by: git grep -E "\w+\.c\<"
> > gt
> Hmm,
On 1/16/19 7:56 AM, David Rowley wrote:> On Tue, 15 Jan 2019 at 08:21,
Tomas Vondra wrote:
>> Turns out you were right - the attribute_referenced piece was quite
>> unnecessary. So I've removed it. I've also extended the regression tests
>> to verify changing type of another column does not
On Wed, Jan 16, 2019 at 02:59:31PM -0300, Alvaro Herrera wrote:
> That's my opinion too, but I was outvoted in another subthread -- see
> https://postgr.es/m/20181214144529.wvmjwmy7wxgmgyb3@alvherre.pgsql
> Stephen Frost, Andrew Gierth and Andres Freund all voted to put
> CONCURRENTLY outside the
On Wed, Jan 16, 2019 at 02:14:41PM +0100, Peter Eisentraut wrote:
> On 15/01/2019 08:13, Michael Paquier wrote:
>> When testing a bulk INSERT into a table which has a stored generated
>> column, memory keeps growing in size linearly, which does not seem
>> normal to me. If inserting more tuples
On Wed, Jan 16, 2019 at 11:02:48AM -0500, Robert Haas wrote:
> I think you have some valid points here, but I also think that the
> patch as written doesn't really seem to have any user-visible
> benefits. Sure, ready_to_display is a crock, but getting rid of it
> doesn't immediately help
>On Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera
>wrote:
>>
>> On 2018-Nov-15, Laurenz Albe wrote:
>>
> > > This new option would not only mitigate the long shared_buffers
> > > scan, it would also get rid of the replication conflict caused by
> > > the AccessExclusiveLock taken during
I couldn't compile v7-0001 and I am testing with the older v6-0001 (of
which I still had an instance).
So the problem below may have been fixed already.
If you add a generated column to a file_fdw foreign table, it works OK
wih VIRTUAL (the default) but with STORED it adds an empty column,
> [v5]
Hi Tomas,
Peter suggested upthread to use 'settings' rather than 'gucs' for the
explain option (and output?), and you seemed to agree. Are you going
to include that in a future version? Speaking of the output, v5's
default text doesn't match that of formatted text ('GUCs' / 'GUC').
On 16/01/2019 14:20, Daniel Verite wrote:
> I've found another issue with aggregates over distinct:
> the deduplication seems to ignore the collation.
I have a fix for that. I'll send it with the next update.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
On 05/01/2019 15:53, Peter Eisentraut wrote:
> On 21/11/2018 15:46, Christoph Berg wrote:
>> A startup looks like this:
>>
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1",
>> port 5431
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address
>>
On 2019-Jan-11, Amit Langote wrote:
> Looking around a bit more, I started thinking even build_child_join_sjinfo
> doesn't belong in appendinfo.c (just to be clear, it was defined in
> prepunion.c before this commit), so maybe we should move it to joinrels.c
> and instead export
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> >>> On reflection, maybe the problem is not that we're giving the file
> >>> the wrong permissions, but
Stephen Frost writes:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
>>> On reflection, maybe the problem is not that we're giving the file
>>> the wrong permissions, but that we're putting it in the wrong place?
> I'm not really
James Coleman writes:
> One other question on testing: do you think the "calculated array"
> tests are good enough by themselves (i.e., remove the ones with array
> constants of > 100 values)? I dislike that it's not as obvious what's
> going on, but given that the code shouldn't care about array
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> > On reflection, maybe the problem is not that we're giving the file
> > the wrong permissions, but that we're putting it in the wrong place?
> > That is, seems like it should
On 2019-Jan-16, Michael Paquier wrote:
> Regarding the grammar, we tend for the last couple of years to avoid
> complicating the main grammar and move on to parenthesized grammars
> (see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
> it would make sense to only support
John Naylor writes:
> It just occured to me that the style FSM_LOCAL_MAP_EXISTS seems more
> common for macros that refer to constants, and FSMLocalMapExists for
> expressions, but I've only seen a small amount of the code base. Do we
> have a style preference here, or is it more a matter of
Andrew Gierth writes:
> Looking into a bug report on the -general list about grouping sets,
> which turns out to be an issue of collation assignment: if the query has
> CASE GROUPING(expr) WHEN 1 ...
> then the expression is rejected as not matching the one in the GROUP BY
> clause, because
I wrote:
> (FWIW, I'm running the patch on gaur's host, just to confirm it
> does what you expect. Should have an answer in an hour or so ...)
It does --- it compiles cleanly, and the float4 output matches
float4-misrounded-input.out.
(This is the v1 patch not v2.)
On Wed, Jan 16, 2019 at 11:40 AM John Naylor
wrote:
On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila
wrote:
can use a macro for the same? I have changed this in the attached
patch, see what you think about it. I have used it at a few other
places as well.
The macro adds clarity, so I'm in
On 2018-Dec-21, Greg Stark wrote:
> But I had a second look to see if the output pointed out any actual
> bugs. I found one though it's pretty minor:
>
> lockfuncs.c:234:3: warning: enumeration value
> ‘LOCKTAG_SPECULATIVE_TOKEN’ not handled in switch [-Wswitch-enum]
>switch ((LockTagType)
On Thu, Nov 22, 2018 at 10:16 AM Peter Eisentraut
wrote:
> On 15/11/2018 15:10, Robert Haas wrote:
> > I don't have a strong position on 1 vs. 2 vs. 3, but I do think it
> > would be nicer not to use '\0' as a column value. I'd suggest you use
> > 'n' or '0' or '-' or some other printable
Looking into a bug report on the -general list about grouping sets,
which turns out to be an issue of collation assignment: if the query has
CASE GROUPING(expr) WHEN 1 ...
then the expression is rejected as not matching the one in the GROUP BY
clause, because CASE already assigned collations
On 1/16/19 9:27 AM, Michael Paquier wrote:> Regarding the grammar, we
tend for the last couple of years to avoid
complicating the main grammar and move on to parenthesized grammars
(see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
it would make sense to only support
On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine wrote:
> One idea would be that if every temp table in the session belongs to the
> transaction, and their namespace too (we could check through pg_depend
> that the namespace doesn't contain anything else beside the
> transaction's tables), then
On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila wrote:
>
> On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> wrote:
> 1.
> Commit message:
> > Any pages with wasted free space become visible at next relation extension,
> > so we still control table bloat.
>
> I think the free space will be available
On Wed, Jan 16, 2019 at 3:30 AM Masahiko Sawada wrote:
> As the above comment says, it's possible that the state of an
> INSERT_IN_PROGRESS tuple could be changed to 'dead' after
> heap_page_prune(). Since such tuple is not truncated at this point we
> record it and set it as UNUSED in
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> See if Windows likes this one any better.
Tom> Doubtful, because AFAICT it's the same patch.
Sigh. copied wrong file. Let's try that again.
--
Andrew (irc:RhodiumToad)
diff --git a/configure b/configure
index
Peter Eisentraut writes:
> On 07/01/2019 00:16, Tom Lane wrote:
>> BTW, this is a pre-existing problem not the fault of this patch,
>> but while we're fooling with the behavior of python lookup would
>> be a great time to fix it: we should add something like
>> AC_ARG_VAR([PYTHON], [path to
On 14/01/2019 15:37, Andreas Karlsson wrote:
>> Nondeterministic collations do address this by allowing canonically
>> equivalent code point sequences to compare as equal. You still need a
>> collation implementation that actually does compare them as equal; ICU
>> does this, glibc does not
On January 16, 2019 8:08:09 AM PST, Robert Haas wrote:
>On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some
>how
>> related to relation caches.
>
On 09/01/2019 09:20, Mi Tar wrote:
> I tested this patch and it applied cleanly and all tests passed. I haven't
> looked if the changes to tests are reasonable or extensive to cover all
> aspects of what they want to cover.
I have committed this with additional tests for partitioned tables, as
On Sat, Jan 12, 2019 at 4:36 PM Thomas Munro
wrote:
> 1. We need a new "bgreader" process to do read-ahead. I think you'd
> want a way to tell it with explicit hints (for example, perhaps
> sequential scans would advertise that they're reading sequentially so
> that it starts to slurp future
Andrew Gierth writes:
> See if Windows likes this one any better.
Doubtful, because AFAICT it's the same patch.
regards, tom lane
Robert Haas writes:
> On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some how
>> related to relation caches.
> Insofar as we can reasonably do so,
See if Windows likes this one any better.
--
Andrew (irc:RhodiumToad)
diff --git a/configure b/configure
index 06fc3c6835..e3176e24e9 100755
--- a/configure
+++ b/configure
@@ -15802,6 +15802,19 @@ esac
fi
+ac_fn_c_check_func "$LINENO" "strtof" "ac_cv_func_strtof"
+if test
On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
wrote:
> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
> because nodes/relation.h is related to planner. utils/rel.h is some how
> related to relation caches.
Insofar as we can reasonably do so, I'd rather pick unique names for
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The errno handling in strtof seems bizarrely overcomplex; why do
> Tom> you need the separate caller_errno variable?
> Eh. I was preserving the conventional behaviour of setting errno only on
> errors and not resetting it to 0,
Oh, I
On Tue, Jan 15, 2019 at 8:48 PM Michael Paquier wrote:
> > So the answer to your question is: the WAL receiver fails to start.
>
> Robert, does this answer your question? I agree that depending on the
> timing, we could finish by having the startup process spawning a WAL
> receiver with a given
> "Tom" == Tom Lane writes:
>> As discussed in the Ryu thread, herewith a draft of a patch to use
>> strtof() for float4 input (rather than using strtod() with its
>> double-rounding issue).
Tom> The errno handling in strtof seems bizarrely overcomplex; why do
Tom> you need the
Andrew Gierth writes:
> As discussed in the Ryu thread, herewith a draft of a patch to use
> strtof() for float4 input (rather than using strtod() with its
> double-rounding issue).
The errno handling in strtof seems bizarrely overcomplex; why do
you need the separate caller_errno variable?
>
>
> On Tue, Jan 15, 2019 at 10:17 AM Shay Rojansky wrote:
> > Unfortunately I'm extremely tight for time at the moment and don't have
> time to do the appropriate hot standby setup to test this... As the patch
> is pretty straightforward, and since I'm hoping you guys execute the tests
> on your
Alexander Kuzmenkov writes:
> The filter is not needed, why is it there? Turns out we can't recognize
> that the restriction clause 'b' and the index clause 'b = true' are
> equivalent.
Yeah, it's intentional that we don't get rid of the extra clause;
it doesn't really seem worth the expense
On Tue, Jan 15, 2019 at 11:37 PM Tom Lane wrote:
> Well, as I said upthread, it seems like we need to think a bit more
> carefully about what it is that clause_is_strict_for is testing ---
> and if that ends up finding that some other name is more apposite,
> I'd not have any hesitation about
As discussed in the Ryu thread, herewith a draft of a patch to use
strtof() for float4 input (rather than using strtod() with its
double-rounding issue).
An exhaustive search shows that this does not change the resulting
bit-pattern for any input string that could have been generated by PG
with
Hello,
I already sent the following message to postgres-xl-developers list but
they don't seem so active. Therefore, I hope you accept this kind of
messages to this mail list.
I'm planning to run PostgreSQL-XL data nodes on CephFS as shared folder. My
goal is to provide scalability (auto/manual)
On Wed, Jan 16, 2019 at 9:25 AM Mithun Cy wrote:
>
> On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> wrote:
> >
> > On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila wrote:
> > > Thanks, Mithun for performance testing, it really helps us to choose
> > > the right strategy here. Once John provides
On Fri, Jan 11, 2019 at 3:54 AM John Naylor wrote:
>
> On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila wrote:
> > Thanks, Mithun for performance testing, it really helps us to choose
> > the right strategy here. Once John provides next version, it would be
> > good to see the results of regular
Peter Eisentraut wrote:
> > On a table with pre-existing contents, the creation of a unique index
> > does not seem to detect the duplicates that are equal per the
> > collation and different binary-wise.
>
> Fixed in the attached updated patch.
Check. I've found another issue with
On 15/01/2019 08:13, Michael Paquier wrote:
> When testing a bulk INSERT into a table which has a stored generated
> column, memory keeps growing in size linearly, which does not seem
> normal to me. If inserting more tuples than what I tested (I stopped
> at 10M because of lack of time), it
On Tue, 15 Jan 2019 at 08:21, Tomas Vondra wrote:
> Turns out you were right - the attribute_referenced piece was quite
> unnecessary. So I've removed it. I've also extended the regression tests
> to verify changing type of another column does not reset the stats.
(Trying to find my feet over
> On Wed, Jan 16, 2019 at 1:16 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Hi,
>
> During the discussion in [1] an idea about refactoring ArchiveEntry was
> suggested. The reason is that currently this function has significant number
> of
> arguments that are "optional", and every change
Hi,
During the discussion in [1] an idea about refactoring ArchiveEntry was
suggested. The reason is that currently this function has significant number of
arguments that are "optional", and every change that has to deal with it
introduces a lot of useless diffs. In the thread, mentioned above,
Hello Tomas,
On 16.01.2019 03:23, Tomas Vondra wrote:
I've looked at the patch today, and in general is seems quite solid to
me. I do have a couple of minor points
1) I think the comments need more work. Instead of describing all the
individual changes here, I've outlined those improvements in
Hi hackers,
Consider this query plan:
create table t (i int, b bool);
create index on t(i, b);
set enable_bitmapscan to off;
explain select * from t where i = 300 and b;
QUERY PLAN
-
Index
Michael-san,
(2019/01/16 15:54), Michael Paquier wrote:
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
(2019/01/07 20:26), Etsuro Fujita wrote:
On second thought I'd like to propose another option:
execute_foreign_modify because I think this would match the existing
helper
(2019/01/16 15:21), Ashutosh Bapat wrote:
On Wed, Jan 16, 2019 at 11:22 AM Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2019/01/15 13:29), Ashutosh Bapat wrote:
> I think, there's something better possible. Two partitioned relations
> won't use partition-wise join, if
On 07/01/2019 00:16, Tom Lane wrote:
> BTW, this is a pre-existing problem not the fault of this patch,
> but while we're fooling with the behavior of python lookup would
> be a great time to fix it: we should add something like
>
> AC_ARG_VAR([PYTHON], [path to Python executable])
>
> Aside
On Wed, Jan 16, 2019 at 2:03 AM Adrien NAYRAT
wrote:
>
> On 1/15/19 11:42 AM, Masahiko Sawada wrote:
> >> When you troubleshoot applicative issues with multi-statements
> >> transaction, you may have to log all queries to find all statements of one
> >> transaction. With high throughput, it
On Tue, Jan 15, 2019 at 2:51 PM Tomas Vondra
wrote:
> What do you mean by "raw statistic"?
>
I mean without further calculation to consider other operation
>
> IMHO the best thing you can do is call estimate_num_groups() and combine
> that with the number of input rows. That shall benefit
On 1/16/19 1:40 AM, Kuroda, Hayato wrote:
By the way, I think the name of this parameter should be changed.
In the Cambridge dictionary, the word "rate" means as follows:
the speed at which something happens or changes,
or the amount or number of times it happens or changes in a particular
On Wed, Jan 16, 2019 at 5:24 AM Robert Haas wrote:
>
> On Mon, Jan 14, 2019 at 9:24 PM Masahiko Sawada wrote:
> > I think that because the tuples that got dead after heap_page_prune()
> > looked are recorded but not removed without lazy_vacuum_page() we need
> > to process them in
st 16. 1. 2019 v 9:26 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 15/01/2019 08:18, Pavel Stehule wrote:
> > I would to have a mechanism for safe replacement of triggers of type
> >
> > if TG_TYPE = 'INSERT' THEN
> > NEW.inserted := CURRENT_TIMESTAMP;
> > ELSE
On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote:
> NOTICE seems unnecessary here.
>
> Unfortunally concurrently reindex loses comments, reproducer:
Yes, the NOTICE message makes little sense.
I am getting back in touch with this stuff. It has been some time but
the core of the
From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> I don't know what PgJDBC is doing, however I think libpq needs to do
> more than just retrying.
>
> 1) Try to find a node on which pg_is_in_recovery() returns false. If
>found, then we assume that is the primary. We also assume that
>other
On 15/01/2019 08:18, Pavel Stehule wrote:
> I would to have a mechanism for safe replacement of triggers of type
>
> if TG_TYPE = 'INSERT' THEN
> NEW.inserted := CURRENT_TIMESTAMP;
> ELSE IF TG_TYPE = 'UPDATE' THEN
> NEW.updated := CURRENT_TIMESTAMP;
> ..
That kind of use is probably better
83 matches
Mail list logo
