On Sat, May 14, 2011 at 8:42 PM, Darren Duncan wrote:
>
> First of all, what if "cast(timestamp as int)" was already defined? Which
> cast then would you expect to be invoked here?
>
> '1800-01-01 00:00:00'::int
>
i will expect an error in that case... what you're doing there is
casting an "unk
- Original Message -
From: "Jaime Casanova"
To: "Tom Lane"
Cc: "PostgreSQL-development"
Sent: Saturday, May 14, 2011 8:29 PM
Subject: Re: [HACKERS] DOMAINs and CASTs
On Sat, May 14, 2011 at 5:13 PM, Tom Lane wrote:
Jaime Casanova writes:
If i create a DOMAIN an then want to cre
- Original Message -
From: "Darren Duncan"
To: "Jaime Casanova"
Cc: "PostgreSQL-development"
Sent: Saturday, May 14, 2011 9:42 PM
Subject: Re: [HACKERS] DOMAINs and CASTs
Jaime Casanova wrote:
If i create a DOMAIN an then want to create a CAST from that domain to
another type it
- Original Message -
From: "Darren Duncan"
To: "Jaime Casanova"
Cc: "PostgreSQL-development"
Sent: Saturday, May 14, 2011 9:46 PM
Subject: Re: [HACKERS] DOMAINs and CASTs
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable for
casts defined
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable
for casts defined on the base type, and if you want a domain-specific
one you should use the function syntax such as your datetime2int().
That way it is easier for users to predict what behavior will occ
Jaime Casanova wrote:
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Consider this example:
"""
create domain datetime as timestamp with time zone
check (value between '1753-01-01 00:00:00' and '-12-31 23:59:59');
create function dat
On Sat, May 14, 2011 at 5:13 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> If i create a DOMAIN an then want to create a CAST from that domain to
>> another type it gives an error.
>
> It's *not* trivial to fix, at least not in a way that gives desirable
> behavior for more than the simplest ca
Jaime Casanova writes:
> If i create a DOMAIN an then want to create a CAST from that domain to
> another type it gives an error.
Yes. See previous discussions about that, e.g. these threads:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php
http://archives.postgresql.org/pgsql-
Mitsuru IWASAKI wrote:
> Are there any good examples for extension module?
Browse the subdirectories of contrib.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I had a chance to give this patch a look. This review is of the second
patch posted by Gurjeet, at:
http://archives.postgresql.org/message-id/AANLkTi=yjb_a+ggt_pxmrqhbhyid6aswwb8h-lw-k...@mail.gmail.com
== Summary ==
This patch implements the \ir command for psql, with a long alias
\include_relati
Hi,
> I'd suggest doing this as an extension module. All the changes to
> existing server code seem superficial.
It sounds interesting. I'll try it later.
Are there any good examples for extension module?
Thanks
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Hi,
> We can't accept patches just based on a pointer to a web site. Please
> e-mail this to the mailing list so that it can be considered a
> submission under the project's licensing terms.
>
> > I hope this would be committable and the final version.
> >
>
> PostgreSQL has high standards
Hi,
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Consider this example:
"""
create domain datetime as timestamp with time zone
check (value between '1753-01-01 00:00:00' and '-12-31 23:59:59');
create function datetime2int(datetime)
On Fri, May 13, 2011 at 5:55 PM, Robert Haas wrote:
> On Fri, May 13, 2011 at 4:16 PM, Noah Misch wrote:
>> I wonder if, instead, we could signal all backends at
>> marker 1 to dump the applicable parts of their local (memory) lock tables to
>> files. Or to another shared memory region, if that
On Sat, May 14, 2011 at 11:37 AM, Tom Lane wrote:
> Yes: it'd introduce a new externally-visible state that libpq now has to
> worry about supporting in all its operations, ie connection closed but
> not gone. This state is guaranteed to be poorly tested and hence buggy.
If you connect to a data
Leon Smith writes:
> ... The low-level binding has a couple of options:
> 1. Ignore the issue and allow for the possibility of a segfault if
> the library is used incorrectly, which is not a good situation for
> "safe" languages.
> 2. Create a wrapper that tracks whether or not PQfinish has e
A minor issue has come up in creating low-level bindings to libpq for
safe garbage-collected languages, namely that PQfinish is the only
(AFAICT) way to close a connection but also de-allocates the memory
used to represent the database connection.It would be preferable
to call PQfinish to free
Robert Haas writes:
> On Fri, May 13, 2011 at 11:05 PM, Noah Misch wrote:
>> Incidentally, I used the term "local lock" because I assumed fast-path locks
>> would still go through the lock manager far enough to populate the local lock
>> table. But there may be no reason to do so.
> Oh, good po
On Fri, May 13, 2011 at 12:10 PM, Kevin Grittner
wrote:
> FWIW, so far what I know is that it will take an example something
> like the one shown here:
>
> http://archives.postgresql.org/pgsql-hackers/2011-02/msg00325.php
>
> with the further requirements that the update in T3 must not be a
> HOT
On Fri, May 13, 2011 at 11:05 PM, Noah Misch wrote:
> Incidentally, I used the term "local lock" because I assumed fast-path locks
> would still go through the lock manager far enough to populate the local lock
> table. But there may be no reason to do so.
Oh, good point. I think we probably WO
20 matches
Mail list logo
