without knowing its own name, which could be
nice in a simple recursive routine. Maybe .(arg,arg) would do it?
I would think this should be non-intrusive and useful and could go in 9.1.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas wrote:
On Sep 8, 2010, at 3:17 PM, Darren Duncan dar...@darrenduncan.net wrote:
Bruce Momjian wrote:
Sergey Konoplev wrote:
3.
CREATE FUNCTION func_very_very_very_very_long_name() RETURNS integer AS $$
func_alias
DECLARE
var_name text := 'bla';
BEGIN
RAISE INFO
(...)
Personally I like the idea of developers not always having to be forced to
choose among two equally good names, and making a wrapper function would be
overkill for this feature.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
now for me to push this shorthand further. --
Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, meaning ones that can
work with any relations like built-ins can, and the ability to iterate over
record fields, or at least introspect a relation to see what fields it has, is a
good foundation to support this. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
syntax to TRUNCATE itself where one can specify which behavior to have,
and both options can be given explicitly to override any config option.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine wrote:
Darren Duncan dar...@darrenduncan.net writes:
So, I'm partly proposing a specific narrow new feature, TRUNCATE FOR EACH
ROW
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely
implicitly stringify. But I can also accept implicit
stringification / language behavior changes if it is a lexical/temporary effect
that the same user is still explicitly turning on.
-- Darren Duncan
Jeff Davis wrote:
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote:
And we not only don't
That sounds like a good change to me. -- Darren Duncan
Craig Ringer wrote:
Hi all
I'm seeing lots of confusion from people about why:
REVOKE CONNECT ON DATABASE foo FROM someuser;
doesn't stop them connecting. Users seem to struggle to understand that:
- There's a default GRANT
be with #2 only, and producing #1 must go through #2.
So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON
respectively.
That's how I think it should work.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
#1 is if we aren't sure we're going to go ahead
with it, and give a few months to think about it before announcing this major
thing suddenly. Waiting until 9.3 just to make an announcement is silly.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
they're
most likely to look, the RULEs documentation, without any undue delay.
How does that sound?
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
all database access would be over a private server-server network, so
the situation isn't as bad as going over the public internet.)
How much trouble would it be to make the
http://www.postgresql.org/download/linux/redhat/ packages include SSL?
-- Darren Duncan
--
Sent via pgsql-hackers
John R Pierce wrote:
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
hmm? I'm using the 9.1 for CentOS 6(RHEL 6
proposal is partly about helping performance by
supporting this internally, rather than one just defining it as a SQL function,
am I right?
-- Darren Duncan
Jeff Davis wrote:
I hope this is not an inappropriate time for 9.3 discussions. The flip
side of asking for submissions in the first couple
interpretations in the
transform.
Ideally the feature would also work not only for interfacing with PLs but also
with client languages, since conceptually its alike but just differing on who
calls who.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
a corresponding type like the regular
table/relation-typed variables in the database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with the DBMS being given only
the view-defining SELECT, where possible. -- Darren Duncan
Dean Rasheed wrote:
I've been playing around with the idea of supporting automatically
updatable views, and I have a working proof of concept. I've taken a
different approach than the previous attempts to implement
take and skip count at once.
Array slicing can be done using foo[first..last] or such.
A random number generator that takes endpoints can take a range argument.
An array or relation of these range can represent ranges with holes, and the
general results of range union operations.
-- Darren
Pavel Stehule wrote:
2011/6/6 Darren Duncan dar...@darrenduncan.net:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages
Jeff Davis wrote:
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what
free to replace all occurrences of
one operand in the program with occurrences of the other, for optimization,
because generic = returning TRUE means one is just as good as the other. This
assumes generally that we're dealing with immutable value types.
-- Darren Duncan
--
Sent via pgsql
Jeff Davis wrote:
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
Can Pg be changed to support . in operator names as long as they don't just
appear by themselves? What would this break to do so?
Someone else would have to comment on that. My feeling is that it might
create problems
of those values.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
types is the root of the problem. The
range-specific stuff can remain ANYELEMENT and no special-casing is required.
Also, besides range constructors, a generic membership test like value in
range is polymorphic. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base
that's my position, CREATE TYPE on the regular types or the like is the best
solution, and anything else is an inferior solution.
Such a design is also how I do collations and ranges in my Muldis D language.
-- Darren Duncan
Jeff Davis wrote:
Different ranges over the same subtype make sense
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over
Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
+ has named subqueries which handle a lot of cases
where temp tables would otherwise be used, I would certainly expect those to
work when you're dealing with a readonly database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Jeff Davis wrote:
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
When you create a temporary table, PostgreSQL needs to add rows in
pg_class, pg_attribute, and probably other system catalogs. So there are
writes, which aren't possible in a read-only transaction. Hence the
error
Jeff Davis wrote:
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres having
support for directly using multiple databases within the same SQL session at
once, as if namespaces were another level deep, the first level
contributions in the meantime. How much or
what I already know may not always come across well. If this bothers people
then I can make more of an effort to reduce my input until I have more solid
things to back them up.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers
SQL.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jeff Davis wrote:
On Fri, 2011-07-08 at 23:39 -0700, Darren Duncan wrote:
What if you used the context of the calling code and resolve in favor of
whatever match is closest to it? The problem is related to general-purpose
programming languages.
Basically start looking in the lexical context
any less relational, because the above definition and any others still hold.
The less relational argument above is a red herring or distraction. One can
argue against namespace nesting just fine without saying that.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers
I will put my support for David Johnston's proposal, in principle, though minor
details of syntax could be changed if using ! conflicts with something. --
Darren Duncan
David Johnston wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Florian Pflug f...@phlo.org wrote:
On Jul11, 2011, at 07:08
it was found now. --
Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that to
represent some things in a more natural manner than a tabular format? JSON is
designed to be machine-parseable, and some objects such as routine definitions
are naturally trees of arbitrary depth. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
to support implementation matters of foreign keys that require
their targets to be unique.)
How much work would it be to support this? But also important, does anyone
either agree it should be supported or does anyone want to counter-argue that it
shouldn't be supported?
-- Darren Duncan
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
Darren Duncan wrote:
From my usage and
http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that
Postgres requires constraints like unique (and primary) keys, and foreign keys,
to range over at least 1 attribute/column.
I
loss of functionality, but users might have to change their code to
do it the one true way, that would seem a good thing. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.03.25 6:03 PM, Darren Duncan wrote:
On 2013.03.25 5:55 PM, Craig Ringer wrote:
On 03/25/2013 10:28 PM, Tom Lane wrote:
Yeah, they are, because things break when they're set wrong.
They also make debugging and support harder; you need to get an
ever-growing list of GUC values from
On 2013.03.26 1:40 AM, Albe Laurenz wrote:
Darren Duncan wrote:
So, determining if 2 rows are the same involves an iteration of dyadic logical
AND over the predicates for each column comparison. Now logical AND has an
identity value, which is TRUE, because TRUE AND p (and p AND TRUE) results
. Are drops the main expected use case for the feature,
rather than tell me when something happened? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.05.09 11:22 AM, Alvaro Herrera wrote:
Darren Duncan wrote:
On 2013.05.09 10:40 AM, Pavel Stehule wrote:
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It looks
really strange and asymmetric
.
-- Darren Duncan
On 2013.05.11 9:27 AM, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a clue what the design
of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE? Or is the VOID-returning FUNCTION going to be deprecated or
discouraged at the same time?
-- Darren Duncan
--
Sent via pgsql-hackers mailing
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
Since Pg's FUNCTION already seems to take on both roles, so overloading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
that it stays in the restrictions of #1 or #2. But if not, then I
think it would be valuable to do so, for assisting reliability and performance.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
about SQL contrasted with typical other
languages is in how query results are typically returned out of band like the
above describes, rather than explicitly either via an OUT/INOUT parameter or as
a function result relation value. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql
Peter Eisentraut wrote:
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
Since Pg's FUNCTION already seems to take on both roles, so
overloading the meaning of the FUNCTION keyword, like what a C
function or a Perl sub does, where returning VOID means procedure,
then what is being added
to implement an activity log, so some kind of IPC would be
going on.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan dar...@darrenduncan.net wrote:
The point being, the answer to how to implement autonomous transactions
could be as simple as, do the same thing as how you manage multiple
concurrent client sessions, more or less. If each client
, but something following an AS being substituted is just wrong.
Is that a bug and if not then what is the rationale for working that way, and
can it be changed?
Meanwhile, what is the best way to write f to work around this misbehavior?
Thank you.
-- Darren Duncan
--
Sent via pgsql-hackers
I meant.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to do object-relational databases, given that
pure functions and immutable data structures are typically the best way to
express anything one would do with them. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
at all by the delay in
migrating repositories while the CVS is cleaned up? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Craig Ringer wrote:
On 25/09/2010 11:51 AM, Darren Duncan wrote:
There should just be a single syntax that works for all types, in the
general case, for testing whether a value is a member of that type, or
alternately whether a value can be cast to a particular type.
snip
Pg already gets
descriptive for them without
worrying whether the language has a pre-defined meaning for the used words.
The quoting also has the nice bonus of making them case-sensitive.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
be easier, too, because keywords formatted like this would just
be a single term rather than having infinite variations due to embedded whitespace.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Andrew Dunstan wrote:
On 09/28/2010 09:31 PM, Darren Duncan wrote:
Code that quotes all of its identifiers, such as with:
FOR EACH var IN array_expr LOOP ...
This doesn't help in the least if the array is an expression rather than
simply a variable - we're not going to start quoting
, and
thankfully 'full' won.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the
catalog so it represents all the details you want to preserve. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
go to postgresql.conf.auto, which consists only of
setting = value in alphabetical order.
(d) We document that settings which are changed manually in
postgresql.conf will override postgresql.conf.auto.
(e) $$profit$$!!
I agree that this looks like an effective solution.
-- Darren Duncan
--
Sent
.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in their runtime-accessible objects.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, loosely speaking.
The association of a multiset-typed attribute of a table with said table is like
the association of a child and parent table in a many-to-one.
So reuse your structure for tables to hold multisets.
-- Darren Duncan
Itagaki Takahiro wrote:
Postgres supports ARRAY data types well
that SQL could
be written in EBCDIC which natively lacks some of the bracketing characters that
ASCII has. Hence, such is an alternative way to spell either { } or [ ] (I
forget which).
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
lowercase, I write undelimited when
the identifier is entirely lowercase, and I delimit ones that have any
uppercase. And by doing this consistently everything works correctly. Since
most of my identifiers are lowercase anyway, the code also reads cleanly in general.
-- Darren Duncan
--
Sent via
Postgres, I have found that as I use and learn Postgres, I'm finding frequently
that how Postgres does things is similar and compatible to how I independently
came up with Muldis D's design; I'm finding more similarities all the time.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan dar...@darrenduncan.net wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just
of intended significant
design improvements/simplifications to the spec proper, though much of this is
hashed out in the laundry list TODO_DRAFT file in github.
-- Darren Duncan
Joe Abbate wrote:
On 09/19/2011 12:40 PM, Christopher Browne wrote:
On Mon, Sep 19, 2011 at 12:20 PM, David Fetter da
set is more minor. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or not in. One should be able to do complements not only of rows but
of columns too. Basic good language design.
-- Darren Duncan
Eric Ridge wrote:
Would y'all accept a patch that extended the SELECT * syntax to let
you list fields to exclude from the A_Star?
Quite regularly I'll be testing queries via
Pavel Stehule wrote:
2011/10/30 Darren Duncan dar...@darrenduncan.net:
I agree that this feature would be quite useful and should be included in
SQL. The exact syntax is less of an issue, but just the ability to cleanly
say select all columns except for these. I have in fact argued
whether that feature is
harmful enough to reject a free working implementation (of otherwise conforming
code quality) from someone who has already gone to the trouble to implement it.
Eric, if you want to implement this, I say more power to you, and I will use it.
-- Darren Duncan
--
Sent via
David Wilson wrote:
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan dar...@darrenduncan.net wrote:
The SQL level is exactly the correct and proper place to do this.
Its all about mathematical parity. That is the primary reason to do it.
- SELECT * gives you a whole set.
- SELECT foo, bar
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
The real question to ask ourselves is, if Eric Ridge is willing to do all the
work to implement this feature, and the code quality is up to the community
standards and doesn't break anything else, then will the code be accepted
with this?
If so, I think that would make the feature even more valuable and more
syntactically clean than I had previously thought.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
}.
Also, a more tenuous connection, Larry Wall likes but as logical modifier.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
proposal is just an enhancement to that. So there is no reason to reject the
complementary columns feature because of the problems with select *; you might
as well argue to get rid of select *. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
}
--
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule wrote:
2011/3/26 Darren Duncan dar...@darrenduncan.net:
I mention 2 possible solutions here, both which involve syntax alterations,
each between the -- lines. I personally like the second/lower
option more.
-1
this is not based on any pattern on SQL. It's not simple
as I seem to
recall having in 8.4. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a replacement.
In any event, QUEL was somewhat similar to SQL.
-- Darren Duncan
Rajasekhar Yakkali wrote:
Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.
... the intention
identifier.
As for the SQL standard for bind parameters, as I recall they use :foo and so
:foo would be the sensitive more general case of that.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql
not going to argue for any
changes to functions.)
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
transaction or savepoint or whatever is specific to a process/auto.
Has anyone else thought of the DBMS as operating system analogy? I don't recall
specifically reading this anywhere, but expect the thought may be common.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers
and an optimization.
Of course, when we know the type of a column/etc isn't going to be VARIANT or
some other union type, then a simple optimization allows us to just store the
value and have its type provided by context rather than the struct.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql
of CURRENT_TIMESTAMP and it knows
that this is a member of the union type of myunion. I see a UNION type as being
like a DOMAIN type in reverse.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
from what we're otherwise
talking about as being union types. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mar may 10 16:21:36 -0400 2011:
Darren Duncan wrote:
To follow-up, an additional feature that would be useful and resembles union
types is the variant where you could declare a union type first and then
separately other types
Robert Haas wrote:
On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
On Tue, May 10, 2011 at 5:19 PM, Darren Duncan dar...@darrenduncan.net wrote:
Examples of open union types could be number, which all the numeric types
compose, and so you can know say that you
.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 110 matches
Mail list logo
