Bruce Momjian wrote:
KaiGai Kohei wrote:
Also, having the per-row value always be present in the row and
controlled by the bitmask seems ideal; it avoids having to add a CREATE
TABLE option.
Sorry, I don't understand why it related to a CREATE TABLE option.
System columns are always allocated
Bruce Momjian wrote:
KaiGai Kohei wrote:
If we use some type of integer, I suggest using this structure for
pg_security:
CREATE TABLE pg_security(
relid oid,
secid int2,
secacl aclitem[],
secext TEXT
);
This allows the per-row value to be a simple int2. It also imp
Robert Haas wrote:
Peter made an excellent point a few emails upthread: there seemed to
be consensus in the September CommitFest that we needed SQL-level
support for row and column level security before we talked about
implementing those features as part of SELinux. I don't see that
we're any cl
"Bramandia Ramadhana" writes:
> Hmm how if an upper level node needs to store (for future use) the
> TupleTableSlot* returned by lower level node, e.g. I create a specialized
> Sort Node which needs to read all tuples from lower level nodes. In this
> case, would it be necessary and sufficient to
I see.
Hmm how if an upper level node needs to store (for future use) the
TupleTableSlot* returned by lower level node, e.g. I create a specialized
Sort Node which needs to read all tuples from lower level nodes. In this
case, would it be necessary and sufficient to make a copy the TupleTableSlot
Robert Haas wrote:
I tried to summarize the proposed options, as follows:
o : meritx : demeritX : unacceptable demerit
* 1 security system column, 1 security feature (DAC or MAC)
o It suitable for a single security system column implementation.
x If a user want to use both of DAC and
Alvaro Herrera writes:
> Tom Lane wrote:
>> 1. Always set a snapshot for SET CONSTRAINTS. This is a minus-one-liner
>> --- just remove it from the exclusion list in PortalRunUtility.
>>
>> 2. Have it set a snapshot only if it finds pending trigger events to
>> fire. This would only require anot
Hi,
Fujii Masao wrote:
> I'd like to define the meaning of "synch rep" again. "synch rep" means:
>
> (1) Transaction commit waits for WAL records to be replicated to the standby
> before the command returns a "success" indication to the client.
>
> (2) The standby has (can read) all WAL fi
Tom Lane wrote:
> 1. Always set a snapshot for SET CONSTRAINTS. This is a minus-one-liner
> --- just remove it from the exclusion list in PortalRunUtility.
>
> 2. Have it set a snapshot only if it finds pending trigger events to
> fire. This would only require another half dozen lines of code,
I wrote:
> The comment in PortalRunUtility asserts loudly that ConstraintsSetStmt
> MUST NOT have a transaction snapshot set before it is executed, but
> I confess that I don't see why not at the moment. We certainly can't
> have it not set a snap if it has any triggers to fire. Comments?
I look
Tom Lane wrote:
Alvaro Herrera writes:
\dew show foreign-data wrappers
\des show foreign servers
\deu show user mappings
I'd prefer "external" rather than foreign, because new users could
confuse the latter with "foreign keys".
--Josh
--
Sent via pgsql-hackers mailing list (pg
Andrew Dunstan writes:
>> Excellent. I checked that psql's colon-variable feature behaves the
>> same. So it looks like the proposed "name: value" syntax would indeed
>> not break any existing features. Barring better ideas I think we should
>> go with that one.
> Does that mean the whitespace
Alvaro Herrera writes:
> \dew show foreign-data wrappers
> \des show foreign servers
> \deu show user mappings
Right, but maybe use "external" rather than "foreign" in the help
so that people recognize what the mnemonic is.
regards, tom lane
--
Sent via pgsq
In connection with fixing
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00620.php
I decided to insert "Assert(ActiveSnapshotSet())" into pg_plan_query,
since any path reaching that function should already have provided
a snapshot. I was bemused to find that this resulted in an assert
fai
Tom Lane wrote:
Michael Meskes writes:
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
Hmm ... actually, ecpg might be a problem here anyway. I know it has
special meaning for :name, but does it allow space between the colon
and the name? If it does then the colon syntax
David Fetter wrote:
> On Fri, Dec 12, 2008 at 08:24:36AM -0500, Tom Lane wrote:
> > I'd suggest "e" for external. "M" for "management" is a pretty
> > useless mnemonic --- what's being managed?
>
> \def, \deu, etc. sound great :)
\dew show foreign-data wrappers
\des show foreign servers
On Fri, Dec 12, 2008 at 08:24:36AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Dimitri Fontaine wrote:
> >> What about \dM prefix, M standing for MED? It seems free in my
> >> 8.3 psql here.
>
> > So \dMf for foreign servers, \dMu for user mappings, etc? That
> > seems good.
>
> I'd sug
Simon Riggs writes:
> On Fri, 2008-12-12 at 13:20 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>>> Solutions can also include
>>> * manual mechanism for setting ndistinct that doesn't keep getting
>>> overwritten by subsequent ANALYZEs
>>
>> Hmm, that might actually be the most practical answer
On Fri, 2008-12-12 at 14:23 -0500, Aidan Van Dyk wrote:
> So when would I have to call that function? Before begin, after begin,
> before commit, or all, to guarentee that know that my application is
> suppose to "delay" calling commit until when sync-mode is actualyl
> synchronous? And then afterw
On Fri, 2008-12-12 at 13:20 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Solutions can also include
> > * manual mechanism for setting ndistinct that doesn't keep getting
> > overwritten by subsequent ANALYZEs
>
> Hmm, that might actually be the most practical answer for large,
> reasonably-
Gregory Stark wrote:
Simon Riggs writes:
The amount of I/O could stay the same, just sample all rows on block. []
It will also introduce strange biases. For instance in a clustered table it'll
think there are a lot more duplicates than there really are because it'll see
lots of similar va
Alvaro Herrera writes:
> I think this is the easiest way out, and the most robust -- we won't be
> bitten by some other operation that the parser may think of doing.
> (Note that utility commands have their snapshot set in
> PortalRunUtility). Also, perhaps this would let us clean the mess in
> p
* Jeff Davis [081212 13:41]:
> On Fri, 2008-12-12 at 08:57 -0500, Aidan Van Dyk wrote:
> > > For (2) we need a full interlock. Given that we don't currently support
> > > multiple streamed standby servers, it seems not much point in
> > > implementing the interlock (2) would require. Should we lea
On Fri, 2008-12-12 at 13:43 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2008-12-12 at 13:18 -0500, Tom Lane wrote:
> >> Could we skip the hyperbole please?
>
> > Some of the ndistinct values are very badly off, and in the common cases
> > I cited previously, consistently so.
>
> >
On Fri, Dec 12, 2008 at 6:31 PM, Simon Riggs wrote:
>
> Why not keep the random algorithm we have now, but scan the block into a
> separate hash table for ndistinct estimation. That way we keep the
> correct random rows for other purposes.
It seems to me that what you have to do is look at a set
On Dec 12, 2008, at 7:05 PM, Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed "name: value" syntax would indeed
not break any existing features. Barring better ideas I think we
should
go with that one.
+1
Best,
Davi
On Fri, Dec 12, 2008 at 6:18 PM, Tom Lane wrote:
> I seem to recall Greg suggesting that there were ways to estimate
> ndistinct without sorting, but short of a fundamental algorithm change
> there's not going to be a win here.
Not sure if you meant me, but I can say the approach I saw documented
>> Perhaps a table-level option to scan the whole table instead of
>> estimating would be appropriate?
>>
> ANALYZE FULL foo ?
I was thinking more like a flag that you could set on the table
itself, that would apply to all future analyzes.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql
Robert Haas escreveu:
>> Which raises the issue, if we could get better statistics by passing
>> the whole table, why not do that when VACUUM ANALYZE is run?
>
> I think the reason is "because the next autovacuum would undo it".
>
Ok, but even if autovacuum will undo it, almost-static-dataset wou
Simon Riggs writes:
> On Fri, 2008-12-12 at 13:18 -0500, Tom Lane wrote:
>> Could we skip the hyperbole please?
> Some of the ndistinct values are very badly off, and in the common cases
> I cited previously, consistently so.
> Once I'm certain the rescue helicopter has seen me, I'll stop waving
On Fri, 2008-12-12 at 08:57 -0500, Aidan Van Dyk wrote:
> > For (2) we need a full interlock. Given that we don't currently support
> > multiple streamed standby servers, it seems not much point in
> > implementing the interlock (2) would require. Should we leave that part
> > for 8.5, or do it now
On Fri, 2008-12-12 at 13:18 -0500, Tom Lane wrote:
> I seem to recall Greg suggesting that there were ways to estimate
> ndistinct without sorting, but short of a fundamental algorithm change
> there's not going to be a win here.
Hash table? Haas Stokes suggests a Bloom filter.
Why not keep the
On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote:
> Or, should I create the feature for the user to confirm whether it's in
> "synch rep" via SQL?
>
I think this would be useful.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On Fri, 2008-12-12 at 13:10 -0500, Tom Lane wrote:
> If we don't
> have at least ballpark-correct figures for cost and number of output
> rows, we'll start making mistakes at higher plan levels.
That's definitely where we are now.
Had a call with a customer today where I said "it's OK, its onl
Simon Riggs writes:
> Solutions can also include
> * manual mechanism for setting ndistinct that doesn't keep getting
> overwritten by subsequent ANALYZEs
Hmm, that might actually be the most practical answer for large,
reasonably-static tables. Especially if we expose the "negative
stadistinct"
Simon Riggs writes:
> As I said, we would only increase sample for ndistinct, not for others.
How will you do that? Keep in mind that one of the things we have to do
to compute ndistinct is to sort the sample. ISTM that the majority of
the cost of a larger sample is going to get expended anyway
On Fri, 2008-12-12 at 18:01 +, Greg Stark wrote:
> I think you need to find two different formulas, one which represents
> a clustered table and one which represents randomly distributed data.
> Then you need a way to measure just how clustered the data is so you
> know how much weight to giv
Alvaro Herrera wrote:
> Tom Lane escribi?:
>
> > If you want ANALYZE to be cheap then you simply don't get to have a
> > trustworthy value of ndistinct.
>
> But then, maybe it's not all that critical that ANALYZE is cheap. For
> example, if we were to rework VACUUM ANALYZE so that on the same pa
Alvaro Herrera wrote:
> Robert Haas escribi?:
> > > Which raises the issue, if we could get better statistics by passing
> > > the whole table, why not do that when VACUUM ANALYZE is run?
> >
> > I think the reason is "because the next autovacuum would undo it".
>
> Is there any way to "merge" th
Alvaro Herrera writes:
> Is there any way to "merge" the statistics? i.e. if a full table scan
> is done to compute precise statistics, and later a regular analyze scan
> is done, then perhaps instead of clobbering the previous stats, you
> merge them with the new ones, thus not completely losing
Simon Riggs writes:
> On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
>> Perhaps a better plan is to try to de-emphasize use of ndistinct,
>> though I concede I have no idea how to do that.
> We don't actually care about the accuracy of the ndistinct much, just
> the accuracy of our answer to
On Fri, 2008-12-12 at 14:03 -0300, Alvaro Herrera wrote:
> Partial vacuum is a roadblock for this though :-(
Actually, perhaps its an enabler for looking at changed stats?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mail
Michael Meskes writes:
> On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
>> Hmm ... actually, ecpg might be a problem here anyway. I know it has
>> special meaning for :name, but does it allow space between the colon
>> and the name? If it does then the colon syntax loses. If it doesn
On Fri, Dec 12, 2008 at 5:33 PM, Simon Riggs wrote:
>> Incidentally we *do* do block sampling. We pick random blocks and then pick
>> random records within those blocks. This was new in, uh, 7.4? 8.0? Sometime
>> around then. It dramatically reduced the i/o requirements but there were long
>> disc
Alvaro Herrera writes:
> Tom Lane escribió:
>> If you want ANALYZE to be cheap then you simply don't get to have a
>> trustworthy value of ndistinct.
> But then, maybe it's not all that critical that ANALYZE is cheap. For
> example, if we were to rework VACUUM ANALYZE so that on the same pass
>
KaiGai Kohei wrote:
> >>> Also, having the per-row value always be present in the row and
> >>> controlled by the bitmask seems ideal; it avoids having to add a CREATE
> >>> TABLE option.
> >> Sorry, I don't understand why it related to a CREATE TABLE option.
> >> System columns are always allocat
KaiGai Kohei wrote:
> > If we use some type of integer, I suggest using this structure for
> > pg_security:
> >
> > CREATE TABLE pg_security(
> > relid oid,
> > secid int2,
> > secacl aclitem[],
> > secext TEXT
> > );
> >
> > This allows
"Robert Haas" writes:
> On Fri, Dec 12, 2008 at 4:04 AM, Simon Riggs wrote:
>>> The existing sampling mechanism is tied to solid statistics.
>>
>> Sounds great, but its not true. The sample size is not linked to data
>> volume, so how can it possibly give a consistent confidence range?
> It is
Hi,
Alvaro Herrera wrote:
> No, the signalling needed here is far simpler than Markus' IMessage
> stuff.
Yup, see also Tom's comment [1].
For Postgres-R I'm currently multiplexing by embedding a message type in
the imessage data itself. So this part is certainly overlapping, yes.
Some of the me
Changes:
- added vacuum_delay_point() in gininsertcleanup
- add trigger to run vacuum by number of inserted tuples from
last vacuum. Number of inserted tuples represents number
of really inserted tuples in index and it is calculated as
tuples_inserted + tuples_updated - tuples_hot_updat
On Fri, 2008-12-12 at 17:05 +, Gregory Stark wrote:
> Simon Riggs writes:
>
> > The amount of I/O could stay the same, just sample all rows on block.
> > Lifting the sample size will help large tables. Will it be perfect? No.
> > But I'll take "better" over "not working at all".
>
> That wi
On Fri, Dec 12, 2008 at 11:57 AM, Gregory Stark wrote:
>> Obviously sandwhiching two values in one column is not going to work.
>> The only question here is whether it's important to simultaneously
>> support both DAC and MAC. As far as I can see, KaiGai is the only one
>> arguing that we don't n
>>> "Robert Haas" wrote:
>> Which raises the issue, if we could get better statistics by
passing
>> the whole table, why not do that when VACUUM ANALYZE is run?
>
> I think the reason is "because the next autovacuum would undo it".
The table has 32.4 million rows.
autovacuum_analyze_scale_fac
>> Peter made an excellent point a few emails upthread: there seemed to
>> be consensus in the September CommitFest that we needed SQL-level
>> support for row and column level security before we talked about
>> implementing those features as part of SELinux. I don't see that
>> we're any closer t
On Fri, 2008-12-12 at 16:10 +, Gregory Stark wrote:
> Uhm, this is a survey of lots of different methods and does lots of
> analysis.
> I don't see any simple conclusions about stability. Perhaps I'm just
> missing
> it in the technical details. Could you point out exactly what part of
> the
>
Robert Haas escribió:
> Peter made an excellent point a few emails upthread: there seemed to
> be consensus in the September CommitFest that we needed SQL-level
> support for row and column level security before we talked about
> implementing those features as part of SELinux. I don't see that
>
Simon Riggs writes:
> The amount of I/O could stay the same, just sample all rows on block.
> Lifting the sample size will help large tables. Will it be perfect? No.
> But I'll take "better" over "not working at all".
That will just raise the table size at which the problems start. It'll still
b
Tom Lane escribió:
> If you want ANALYZE to be cheap then you simply don't get to have a
> trustworthy value of ndistinct.
But then, maybe it's not all that critical that ANALYZE is cheap. For
example, if we were to rework VACUUM ANALYZE so that on the same pass
that VACUUM cleans each heap page
Robert Haas escribió:
> > Which raises the issue, if we could get better statistics by passing
> > the whole table, why not do that when VACUUM ANALYZE is run?
>
> I think the reason is "because the next autovacuum would undo it".
Is there any way to "merge" the statistics? i.e. if a full table
On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
> Perhaps a better plan is to try to de-emphasize use of ndistinct,
> though I concede I have no idea how to do that.
We don't actually care about the accuracy of the ndistinct much, just
the accuracy of our answer to the question "given work_me
"Robert Haas" writes:
> Obviously sandwhiching two values in one column is not going to work.
> The only question here is whether it's important to simultaneously
> support both DAC and MAC. As far as I can see, KaiGai is the only one
> arguing that we don't need to do that (except for Tom, who
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
> Hmm ... actually, ecpg might be a problem here anyway. I know it has
> special meaning for :name, but does it allow space between the colon
> and the name? If it does then the colon syntax loses. If it doesn't
No. Here's the lexer rule
On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
> If you want ANALYZE to be cheap then you simply don't get to have
> a trustworthy value of ndistinct.
Understood, but a cheap ANALYZE isn't always a higher priority than all
other considerations.
Solutions can also include
* allowing user t
On Fri, 2008-12-12 at 16:10 +, Gregory Stark wrote:
> Right, but increasing our sample size by a factor of 150 for a 100M
> row table doesn't seem like a reasonable solution to one metric being
> bogus.
>
> For that matter, if we do consider sampling 5% of the table we may as
> well just go a
> Which raises the issue, if we could get better statistics by passing
> the whole table, why not do that when VACUUM ANALYZE is run?
I think the reason is "because the next autovacuum would undo it".
Perhaps a table-level option to scan the whole table instead of
estimating would be appropriate?
> I tried to summarize the proposed options, as follows:
>
> o : meritx : demeritX : unacceptable demerit
>
> * 1 security system column, 1 security feature (DAC or MAC)
> o It suitable for a single security system column implementation.
> x If a user want to use both of DAC and MAC concu
On Dec 12, 2008, at 4:06 PM, Tom Lane wrote:
"David E. Wheeler" writes:
Hrm. I can see that, I guess. In that case, though, I think I'd
prefer
the colon at the beginning of the parameter label:
SELECT foo( :bar => 'ick', :baz => 'ack' );
That's ugly, and incompatible with ecpg syntax,
On Fri, Dec 12, 2008 at 10:31 AM, Greg Stark wrote:
> On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
> wrote:
>> That's why I'm preferring the common-lisp syntax of :param value, or its
>> variant param: value.
>
> FWIW there is no such common-lisp syntax. Colon is just a regular
> symbol char
>>> "Nathan Boley" wrote:
> Can anyone suggest a good data set to test this sort of question on?
Where we have the biggest problem with bad estimates is on complex
searches involving many joins where the main criterion limiting the
result set is a name. The estimate based on the histogram is o
Gregory Stark writes:
> For that matter, if we do consider sampling 5% of the table we may as well
> just go ahead and scan the whole table. It wouldn't take much longer and it
> would actually produce good estimates.
Yeah. Anything over a small fraction of a percent is going to imply
fetching e
Simon Riggs writes:
> On Fri, 2008-12-12 at 06:44 -0500, Robert Haas wrote:
>> It is a pretty well-known mathematical fact that for something like an
>> opinion poll your margin of error does not depend on the size of the
>> population but only on the size of your sample.
>
> Yes, I agree with th
any news on that front ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
wrote:
> That's why I'm preferring the common-lisp syntax of :param value, or its
> variant param: value.
FWIW there is no such common-lisp syntax. Colon is just a regular
symbol character and :param is just a regular symbol in common-lisp.
There
Heikki Linnakangas writes:
> We could do it the other way round:
> SELECT foo( 'ick' AS bar, 'ack' AS baz);
Yeah, that's the direction I had always assumed that we would use,
if AS is the chosen syntax for this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 12 déc. 08 à 15:57, Gregory Stark a écrit :
These don't solve anything. There's nothing stopping you from
defining a unary
prefix operator => or =
That's why I'm preferring the common-lisp syntax of :param value, or
its variant param: value.
"Greg Stark" writes:
> On Fri, Dec 12, 2008 at 2:35 PM, Tom Lane wrote:
>> But having said that, I have wondered whether we should consider
>> allowing the sample to grow to fill maintenance_work_mem
> Hm, so I wonder what this does to the time analyze takes. I think it
> would be the only thing
On Fri, 2008-12-12 at 09:35 -0500, Tom Lane wrote:
> AFAICS, marginal enlargements in the sample size aren't going to help
> much for ndistinct --- you really need to look at most or all of the
> table to be guaranteed anything about that.
>
> But having said that, I have wondered whether we sho
"David E. Wheeler" writes:
> Hrm. I can see that, I guess. In that case, though, I think I'd prefer
> the colon at the beginning of the parameter label:
>SELECT foo( :bar => 'ick', :baz => 'ack' );
That's ugly, and incompatible with ecpg syntax, and what's the redeeming
value anyway?
In a
On Dec 12, 2008, at 3:56 PM, Pavel Stehule wrote:
Hrm. I can see that, I guess. In that case, though, I think I'd
prefer the
colon at the beginning of the parameter label:
SELECT foo( :bar => 'ick', :baz => 'ack' );
this syntax is used yet
http://www.postgresql.org/docs/8.3/interactive/app-
On Dec 12, 2008, at 3:57 PM, Gregory Stark wrote:
In any case this is all weird. SQL isn't C and doesn't have random
bits of
punctuation involved in syntax. It uses whole words for just about
everything.
Anything you do using punctuation characters is going to look out of
place.
Well, wha
On Fri, 2008-12-12 at 06:44 -0500, Robert Haas wrote:
> On Fri, Dec 12, 2008 at 4:04 AM, Simon Riggs wrote:
> >> The existing sampling mechanism is tied to solid statistics. It
> >> provides the correct sample size to get a consistent confidence range
> >> for range queries. This is the same math
2008/12/12 David E. Wheeler :
> On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:
>
>> I discussed about this form with Tom.
>>
>> I thing so following should be readable:
>>
>> name: [ optional => ] value
>>
>> SELECT foo( bar: 'ick', baz: 'ack' );
>> SELECT foo( bar: => 'ick', baz: => 'ack' );
Peter Eisentraut wrote:
KaiGai Kohei wrote:
I would like to be able to assign SQL-level ACLs and SELinux labels
to the same row at the same time in the same build, and have the
system enforce both on top of each other.
In my opinion, it makes more pains (user-interface, performance,
complexi
"Pavel Stehule" writes:
> 2008/12/12 Heikki Linnakangas :
>
>> We could do it the other way round:
>>
>> SELECT foo( 'ick' AS bar, 'ack' AS baz);
I always assumed we were talking about it this way. Everywhere else in SQL AS
is followed by the labels, not the values.
> I discussed about this for
"Robert Haas" writes:
> On Thu, Dec 11, 2008 at 10:12 PM, Tom Lane wrote:
>> Maybe so. If we stick to the other design (end both lists at a preset
>> frequency threshold) then the math clearly goes through the same as
>> before, just with num_mcvs that are determined differently. But can
>> we
On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:
I discussed about this form with Tom.
I thing so following should be readable:
name: [ optional => ] value
SELECT foo( bar: 'ick', baz: 'ack' );
SELECT foo( bar: => 'ick', baz: => 'ack' );
or
SELECT foo( bar: = 'ick', baz: = 'ack' );
rea
On Fri, Dec 12, 2008 at 2:35 PM, Tom Lane wrote:
> AFAICS, marginal enlargements in the sample size aren't going to help
> much for ndistinct --- you really need to look at most or all of the
> table to be guaranteed anything about that.
Well you only need to maintain a fixed percentage of the ta
2008/12/12 Heikki Linnakangas :
> David E. Wheeler wrote:
>>
>> Coming to this a bit late, but it seems to me that, while it makes sense
>> to assign a label to a value using "AS", it's kind of weird to use it to
>> assign a value to a label.
>>
>> SELECT foo( bar => 'ick', baz => 'ack' );
>> SELEC
> I'm okay with AS if that's the way it has to be, but what about a colon
> right at the end of the label? A cast is two colons, so no conflict there:
>
> SELECT foo(1, name: 'bar', quantity: 10);
>
> No doubt I'm missing something…
I'd just like to mention that there are two different cases to
c
David E. Wheeler wrote:
Coming to this a bit late, but it seems to me that, while it makes sense
to assign a label to a value using "AS", it's kind of weird to use it to
assign a value to a label.
SELECT foo( bar => 'ick', baz => 'ack' );
SELECT foo( bar AS 'ick', baz AS 'ack' );
We could do
I wrote:
> "Rod Taylor" writes:
>> How about IS or INTO?
> IS isn't a fully reserved word, and INTO seems pretty weird for this.
> (IS is a type_func_name_keyword, so maybe we could make it work anyway,
> but it sounds a bit fragile.)
Actually, there's an obvious counterexample for IS:
>> right at the end of the label? A cast is two colons, so no conflict there:
>>
>> SELECT foo(1, name: 'bar', quantity: 10);
>
> it's look well, but I still prefer some combination with =
>
> name: = ''
> name: => '''
> :name = ''
> $name => ..
> $name = ..
hmm :( $name isn't possible
:name is i
On Fri, Dec 12, 2008 at 09:00:52AM -0500, Rod Taylor wrote:
> How about IS or INTO?
>
> param_name IS 3
> param_name IS 'some string value'
that wouldn't work with NULL would it? for example is:
a IS NULL
checking if identifier 'a' IS NULL, or if you're giving NULL to
parameter 'a'.
> 3 INT
On Dec 12, 2008, at 2:47 PM, Pavel Stehule wrote:
it's look well, but I still prefer some combination with =
name: = ''
name: => '''
:name = ''
$name => ..
$name = ..
Maybe I am too conservative
Given that the colon already indicates "This label corresponds to that
value", the other operat
In my gripe/suggestion here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00642.php
I noted that it might be nice to handle check constraints over
composite types. It turns out that table check constraints are not
enforced during casts:
postgres=# create table foo(f1 int, f2 int, chec
"Rod Taylor" writes:
> How about IS or INTO?
IS isn't a fully reserved word, and INTO seems pretty weird for this.
(IS is a type_func_name_keyword, so maybe we could make it work anyway,
but it sounds a bit fragile.)
regards, tom lane
--
Sent via pgsql-hackers mailing
Alvaro Herrera writes:
> Tom Lane wrote:
>> 1. Ensure that a snapshot is set before doing parse analysis of any
>> non-utility command.
> I think this is the easiest way out, and the most robust -- we won't be
> bitten by some other operation that the parser may think of doing.
Yeah. I think we
How about IS or INTO?
param_name IS 3
param_name IS 'some string value'
3 INTO param_name
'some string value' INTO param_name
On Fri, Dec 12, 2008 at 8:47 AM, Pavel Stehule wrote:
> 2008/12/12 David E. Wheeler :
>> On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:
>>
>>> So I think that really th
Peter Eisentraut wrote:
> Now the way I read the FDWs you provide (default and pgsql), you are
> creating your own API for initialization and options validation that is
> not in the standard. That would appear to contradict the idea of a
> standard interface. I understand that option validation i
* Simon Riggs [081212 08:20]:
>
> 2. Commit will wait *until* full sync rep is available. So we don't
> allow it until standby fails and also don't allow it if standby goes
> down.
> This provides "Highest Transaction Durability", though is fairly
> fragile. Other systems recommend use of multipl
1 - 100 of 135 matches
Mail list logo
