| Lists: | pgsql-hackers |
|---|
| From: | Chris Forno <chris(at)forno(dot)us> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Adding nullable indicator to Describe |
| Date: | 2010-11-17 05:01:57 |
| Message-ID: | AANLkTimU-HUqikGxgu1Tv0a3wJu4P2WndEuSDAXPk70i@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
I'd like to add information about whether or not a parameter or result can
potentially be NULL to the RowDescription message.
Reason: I have the same reasons that Richard Jones did in 2006 (
http://archives.postgresql.org/pgsql-interfaces/2006-01/msg00043.php). I'm
writing a Haskell library that derives the types of the result at
compile-time. For nullable columns, it needs to know in advance to wrap the
type in the Maybe monad. Looking at the table column information is great,
but I'd like to support the case where a function is used in the SELECT
(among any other potential cases).
I'm new to the code base. Can you point me in the right direction?
I'd like to add the indicator without making the protocol
backwards-incompatible. My first thought was to use a bit in the type
modifier field, but that doesn't seem safe. Any suggestions?
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris Forno <chris(at)forno(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Adding nullable indicator to Describe |
| Date: | 2010-11-17 05:36:00 |
| Message-ID: | 16334.1289972160@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Chris Forno <chris(at)forno(dot)us> writes:
> I'd like to add information about whether or not a parameter or result can
> potentially be NULL to the RowDescription message.
There is noplace to put that without a FE/BE protocol break; and it's
not worth it by itself. This is one of a number of things that we'll
probably consider when we reach a critical mass of reasons to change
the protocol, but AFAICS we are not very close to that now.
So, to be blunt, a patch to do that would be dead on arrival, or at
least would get filed in the "maybe someday but not now" queue.
The other significant problem that you'd face is obtaining the
information to start with. It'd really be impractical to mark a result
column as known-not-null except in the very trivial case where it comes
directly from a not-null table column. Which, as was noted in that old
thread you mentioned, you could get from the system catalogs today given
the information that's already in RowDescription. There isn't any
infrastructure in the backend that would enable deduction of this
property for other cases.
Since this has come up before, I've added the point to
http://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes
but I'm afraid it's unlikely to go much further than that for awhile.
regards, tom lane